[Bug tree-optimization/104825] [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:840

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

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

--- Comment #2 from Richard Biener  ---
Similar to PR103987.  Testing patch.

[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy

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

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

--- Comment #1 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #0)
> I believe this should be rejected as the rank is not known without a MOLD.

That's now an interpretation request:
https://j3-fortran.org/doc/year/22/22-146.txt

(Note: might see updates, such as 22-146r1.txt or ...)

 * * *

In the email thread, also an issue related to C_SIZEOF was mentioned:
https://j3-fortran.org/doc/year/22/22-101r1.txt

Example from the IR, see IR for details about the validity.

program p
 use iso_c_binding
 implicit none
 integer(c_int), pointer :: int_s
 integer(c_int), pointer :: int_a(:)
 print *, c_sizeof (c_null_ptr) ! (A)
 print *, c_sizeof (null ())! (B)
 print *, c_sizeof (null (int_s)) ! (C)
 print *, c_sizeof (null (int_a)) ! (D)
end

[Bug fortran/104827] [12 Regression] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.cc:8329

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P4

[Bug fortran/104826] [11/12 Regression] ICE in gimple_range_global, at value-query.cc:424

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.3
   Priority|P3  |P2
   Keywords||ice-on-valid-code
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
I think we have a duplicate of this (but it was fixed already?!)

(gdb) p name
$1 = 
(gdb) p debug_tree (name)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7652f738 precision:64 min  max 
pointer_to_this >

def_stmt 
version:2>
$2 = void
(gdb) bt
#0  0x00dd69e4 in is_a_helper::test (gs=)
at /home/rguenther/src/gcc3/gcc/gimple.h:1243
#1  0x00dd8f50 in is_a (p=)
at /home/rguenther/src/gcc3/gcc/is-a.h:232
#2  0x01967e67 in gimple_range_global (
name=)
at /home/rguenther/src/gcc3/gcc/value-query.cc:424
#3  0x029eadda in ranger_cache::get_global_range (this=0x413c508, 
r=..., name=)
at /home/rguenther/src/gcc3/gcc/gimple-range-cache.cc:923
#4  0x029e778f in gimple_ranger::export_global_ranges (this=0x413c4e0)
at /home/rguenther/src/gcc3/gcc/gimple-range.cc:474
#5  0x02a40694 in pass_walloca::execute (this=0x411c290, 
fun=0x7670c000)
at /home/rguenther/src/gcc3/gcc/gimple-ssa-warn-alloca.cc:381
#6  0x013b4749 in execute_one_pass (
pass=)
at /home/rguenther/src/gcc3/gcc/passes.cc:2637

[Bug tree-optimization/104825] [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:840

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[andrew at sifive dot com via Gcc-bugs]

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

--- Comment #8 from Andrew Waterman  ---
Cool, thanks, Patrick.


On Mon, Mar 7, 2022 at 6:58 PM patrick at rivosinc dot com via
Gcc-bugs  wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
>
> Patrick O'Neill  changed:
>
>What|Removed |Added
> 
>   Attachment #52577|0   |1
> is obsolete||
>
> --- Comment #7 from Patrick O'Neill  ---
> Created attachment 52578
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52578&action=edit
> Patch v2
>
> Patch submitted to mailing list.
>
> Subject: [PATCH v2] RISCV: Strengthen libatomic lrsc pairs

Re: [Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[Andrew Waterman]

Cool, thanks, Patrick.


On Mon, Mar 7, 2022 at 6:58 PM patrick at rivosinc dot com via
Gcc-bugs  wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
>
> Patrick O'Neill  changed:
>
>What|Removed |Added
> 
>   Attachment #52577|0   |1
> is obsolete||
>
> --- Comment #7 from Patrick O'Neill  ---
> Created attachment 52578
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52578&action=edit
> Patch v2
>
> Patch submitted to mailing list.
>
> Subject: [PATCH v2] RISCV: Strengthen libatomic lrsc pairs

[Bug c++/104618] [12 Regression] trunk 20220221 on x86_64-linux-gnu ICEs building sh.cc for sh4-linux-gnu (in build_call_a, at cp/call.cc:381)

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Should be fixed, yes.

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #52577|0   |1
is obsolete||

--- Comment #7 from Patrick O'Neill  ---
Created attachment 52578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52578&action=edit
Patch v2

Patch submitted to mailing list.

Subject: [PATCH v2] RISCV: Strengthen libatomic lrsc pairs

[Bug libgcc/104833] New: disable-threads don't work for x86_64-linux-gnu target

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 104833
   Summary: disable-threads don't work for x86_64-linux-gnu target
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
   35 | #include 
  |  ^~~
compilation terminated.
In file included from ../../../../../../../gcc/libgcc/gthr.h:148,
 from ../../../../../../../gcc/libgcc/libgcov-interface.c:27:
./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
   35 | #include 
  |  ^~~
compilation terminated.
In file included from ../../../../../../../gcc/libgcc/gthr.h:148,
 from ../../../../../../../gcc/libgcc/unwind-dw2.c:37:
./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
   35 | #include 
  |  ^~~


../../../../gcc/configure --disable-nls --disable-werror
--target=x86_64-ubuntu-linux-gnu --prefix=$PREFIX --disable-libstdcxx-verbose
--enable-languages=c,c++ --disable-hosted-libstdcxx --without-headers
--disable-shared --enable-multilib --with-multilib-list=m64,m32,mx32
--with-gxx-libcxx-include-dir=$PREFIX/$TARGET/include/c++/v1
--disable-decimal-float --disable-threads --with-newlib

I build glibc after libgcc since it needs multilib support. this does not seem
to work correctly

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #6 from Patrick O'Neill  ---
I just reviewed the manual - I was incorrect. Appendix A is correct. I forgot
that the RISCV implementation used leading fences. The second litmus test is no
longer valid since a simple load/store with no fence would not occur in
outputted RISCV asm. The load/store would have a leading fence that would
prevent it from entering the LR/SC pairing.

[Bug go/104832] New: gccgo / libgo Reproducibility Problem

[toolybird at tuta dot io via Gcc-bugs]

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

Bug ID: 104832
   Summary: gccgo / libgo Reproducibility Problem
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: toolybird at tuta dot io
CC: cmang at google dot com
  Target Milestone: ---

TL;DR -> Different binaries are produced depending on whether gccgo is already
installed on the host or not.

Background: I'm looking into broad issues of reproducibility in the context of
bootstrapping whole toolchains.

I first noticed this problem with gcc-11.2.0 but it's still present on GCC
trunk.

To reproduce, you will need to have the same version of gccgo installed on your
host in /usr.

For example, with current GCC trunk:

$ cat gcc/BASE-VER
$ 12.0.1

Step 1:
bootstrap GCC with `--enable-languages=c,c++,go --prefix=/usr
--libexecdir=/usr/lib' then install into a temp DESTDIR.

Step 2:
Uninstall gccgo from the host, or you can fudge it with:

$ sudo mv /usr/lib/go /usr/lib/go.XX

Step 3:
bootstrap GCC again with `--enable-languages=c,c++,go --prefix=/usr
--libexecdir=/usr/lib' then install into a 2nd temp DESTDIR.

Step 4: diff / compare the binaries in the DESTDIRs and you will see
differences.

Delving deeper and diffing the gcc-build dirs, there are a number of object
files affected. A list sorted with `ls -altr' is at the end of this report.

Here is a demonstration with "libgo/fmt.o" (although I suspect the real problem
is further up the chain):

$ cd gcc-build/x86_64-pc-linux-gnu/libgo

$ /build/gcc/src/gcc-build/./gcc/gccgo -B/build/gcc/src/gcc-build/./gcc/
-minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=fmt
../../../gcc/libgo/go/fmt/doc.go ../../../gcc/libgo/go/fmt/errors.go
../../../gcc/libgo/go/fmt/format.go ../../../gcc/libgo/go/fmt/print.go
../../../gcc/libgo/go/fmt/scan.go -o fmt-test1.o

$ sudo mv /usr/lib/go /usr/lib/go.XX

$ /build/gcc/src/gcc-build/./gcc/gccgo -B/build/gcc/src/gcc-build/./gcc/
-minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=fmt
../../../gcc/libgo/go/fmt/doc.go ../../../gcc/libgo/go/fmt/errors.go
../../../gcc/libgo/go/fmt/format.go ../../../gcc/libgo/go/fmt/print.go
../../../gcc/libgo/go/fmt/scan.go -o fmt-test2.o

$ diff fmt-test1.o fmt-test2.o
Binary files fmt-test1.o and fmt-test2.o differ

The differences are in the ".go_export" section of the ELF file.

Using "strings" helps to visualize the differences:

$ strings fmt-test1.o > 1.txt
$ strings fmt-test2.o > 2.txt
$ diff -u 1.txt 2.txt
--- 1.txt   2022-03-08 11:07:01.577545105 +1100
+++ 2.txt   2022-03-08 11:07:06.364263769 +1100
@@ -860,7 +860,7 @@
 import utf8 unicode/utf8 "unicode/utf8"
 init fmt fmt..import errors errors..import cpu internal_1cpu..import oserror
internal_1oserror..import poll internal_1poll..import reflectlite
internal_1reflectlite..import testlog internal_1testlog..import io io..import
fs io_1fs..import math math..import os os..import path path..import reflect
reflect..import runtime runtime..import sort sort..import strconv
strconv..import sync sync..import syscall syscall..import time time..import
unicode unicode..import abi ~internal_1abi bytealg ~internal_1bytealg fmtsort
~internal_1fmtsort goarch ~internal_1goarch goexperiment
~internal_1goexperiment goos ~internal_1goos itoa ~internal_1itoa race
~internal_1race execenv ~internal_1syscall_1execenv unix
~internal_1syscall_1unix unsafeheader ~internal_1unsafeheader bits ~math_1bits
atomic ~runtime_1internal_1atomic math ~runtime_1internal_1math sys
~runtime_1internal_1sys atomic ~sync_1atomic utf8 ~unicode_1utf8
 init_graph 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 10 0 11 0 12 0 13 0 14 0 15 0
16 0 17 0 18 0 19 1 2 1 5 1 13 3 1 3 2 3 5 3 13 4 1 4 2 4 3 4 5 4 7 4 13 4 16 4
17 4 18 5 2 5 13 6 2 6 13 6 16 7 1 7 2 7 5 7 13 7 16 8 1 8 2 8 3 8 5 8 7 8 11 8
13 8 14 8 16 8 17 8 18 9 2 10 1 10 2 10 3 10 4 10 5 10 6 10 7 10 8 10 11 10 13
10 14 10 16 10 17 10 18 11 1 11 2 11 5 11 13 12 1 12 2 12 5 12 9 12 13 12 15 12
16 12 19 13 2 14 2 14 5 14 13 15 1 15 2 15 5 15 9 15 13 16 2 16 13 17 1 17 2 17
3 17 5 17 13 17 16 18 1 18 2 18 3 18 5 18 13 18 16 18 17
-types 41 7 29 30 29 27 25 28 1067 3172 30 335 26 30 34 35 30 88 92 47 88 47 34
34 18 18 19 115 171 21 22 195 60 46 83 61 73 295 73 44 74 22
+types 41 7 29 30 29 27 25 28 1067 3172 30 335 26 30 34 35 30 88 92 47 88 47 38
34 18 18 19 115 171 21 22 195 60 46 83 61 73 295 73 44 74 22
 type 1 "Formatter" 
 type 2 "GoStringer" 
 type 3 "ScanState" 
@@ -972,7 +972,7 @@
 type 18 (? , ? ) 
 type 19 (? , ? , ? , ? , ? )

 type 20 (? , ? ) 
-type 21 (? ) 
+type 21 (? ) (? )
 type 22 (? ) 
 type 23 *
 type 24 *
@@ -1067,7 +1067,7 @@
   $ret10 = $convert(, $false) //577
   return //577
  } //0

-checksum 22D2C8F1A933DC5F8B8E981917B8ADA04DEB2FC1
+checksum A916C151E089AA7EC237CBEBBE2B293A9595478C
 ScanState's Read should not be called. Use ReadRune
 fmt: scanni

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug rtl-optimization/104777] [9/10/11/12 Regression] gcc crashes while compiling a custom coroutine library sample

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Priority|P3  |P2
 Status|NEW |ASSIGNED

--- Comment #7 from Marek Polacek  ---
Comment 6 testcase started with r270550.

I've posted a patch.

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #5 from Patrick O'Neill  ---
IIUC, Appendix A is incorrect.

We cannot allow any memory ops to enter within the LR/SC pair, since a
reordering like that is visible to other threads.

Here's a litmus test showing this fact:

(*
  LR/SC with .aq .rl bits does not allow read operations to be reordered
  within/beneath it.
*)

{
0:x6=a; 0:x8=b;
1:x6=a; 1:x8=b;
}

 P0 | P1  ;
 lw x5,0(x6)| ori x1,x0,1 ;
 lr.w.aq.rl x7,0(x8)| sw x1,0(x8) ;
 ori x1,x0,1| fence rw,rw ;
 sc.w.aq.rl x1,x1,0(x8) | sw x1,0(x6) ;

~exists (0:x5=1 /\ 0:x7=0 /\ b=1)

In a sequentially consistent atomic operation (which this LRSC pair is
emulating), it is not possible for both x5 to be loaded with a 1 and the
LR/SC pair to load/operate on a 0.

With the pairing of LR.aq/SC.aqrl this outcome is possible.

Similarly, for LR.aqrl/SC.rl, a similar reordering needs to be forbidden:

RISCV LRSC-WRITE

(* 
  LR/SC with .aq .rl bits does not allow write operations to be reordered
  within/above it.
*)

{
0:x8=b; 0:x10=c;
1:x8=b; 1:x10=c;
}

 P0 | P1  ;
 ori x9,x0,1| lw x9,0(x10);
 lr.w.aq.rl x7,0(x8)| fence rw,rw ;
 ori x7,x0,1| lw x7,0(x8) ;
 sc.w.aq.rl x1,x7,0(x8) | ;
 sw x9,0(x10)   | ;

~exists (1:x9=1 /\ 1:x7=0 /\ b=1)

In a sequentially consistent atomic operation, it is not possible for
both Hart 1's x9 to be loaded with a 1 and Hart 1's x7 to be loaded with a 0
(as long as the SC succeeds, which b=1 enforces).

That outcome is possible with LR.aqrl/SC.rl since operations can get
reordered within the LR/SC pairing.

[Bug middle-end/98503] [11/12 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da

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

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

--- Comment #17 from Martin Sebor  ---
*** Bug 104341 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/104341] [12 Regression] Bogus -Werror=array-bounds since r12-2582-gb9cbf8c9e0bc72f5

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
By using a larger type to access a smaller object the code violates the strict
aliasing rule, and this instance of the warning for it is intended.  The
problem can be reduced to the following test case where GCC points out the
aliasing violation by -Wincompatible-pointer-types, besides also issuing
-Warray-bounds.

The warning could stand to be rephrased to make the problem clearer and moved
under the -Wstrict-alising option (which would also avoid it in code bases like
the Linux kernel that use -fno-strict-aliasing).  I submitted a patch to do all
that last March in an effort to resolve pr98503 of which this effectively a
duplicate, but the reviewer declined to approve it.

$ cat pr104341.c && gcc -O2 -S -Wall pr104341.c
int acpi_sx_zsdt_acpi;

void f (void)
{
  union {
int u32[2];
  } *d = &acpi_sx_zsdt_acpi;

  d->u32[0] = 0;
}
pr104341.c: In function ‘f’:
pr104341.c:7:10: warning: initialization of ‘union  *’ from
incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
7 |   } *d = &acpi_sx_zsdt_acpi;
  |  ^
pr104341.c:9:4: warning: array subscript ‘union [0]’ is partly
outside array bounds of ‘int[1]’ [-Warray-bounds]
9 |   d->u32[0] = 0;
  |^~
pr104341.c:1:5: note: object ‘acpi_sx_zsdt_acpi’ of size 4
1 | int acpi_sx_zsdt_acpi;
  | ^

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

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dinuxbg at gmail dot com,
   ||vries at gcc dot gnu.org,
   ||wschmidt at linux dot ibm.com

--- Comment #29 from Eric Gallager  ---
(In reply to Roland Illig from comment #17)
> From bfin.cc:
> > cannott
> 
> Should be "cannot".

Martin L was last to touch in 58385f6a (ironically, a -Wformat-diag fix)

(In reply to Roland Illig from comment #18)
> From nds32.cc:
> > this built-in function not support on the v3m toolchain
> 
> "support" should be "supported".

uh... closest thing I can find is a string that now reads "not support
%<-fpic%> option for v3m toolchain" at line 4149; `git blame` says Martin L was
last to touch in a3f9f006 

(In reply to Roland Illig from comment #19)
> From nvptx.cc:
> > PTX version (-mptx) needs to be at least %s to support selected -misa 
> > (sm_%s)
> 
> Missing %<...%> around -mptx and -misa.

Tom DeVries's string (decde111)

(In reply to Roland Illig from comment #20)
> From pru.cc:
> > register name %<%s%>
> 
> Please use the canonical %qs instead of the unnecessarily verbose %<%s%>.
> Everywhere.

Dimitar Dimitrov's string (8bafc964)

(In reply to Roland Illig from comment #21)
> From rs6000-c.cc:
> > passing argument %d of %qE discards const qualifier from pointer target type
> 
> The word "const" must be in % quotes.

Bill Schmidt's string (93b5a667)

(In reply to Roland Illig from comment #22)
> From v850-c.cc:
> > %<#pragma%> GHS end found without previous startXXX
> > %<#pragma%> GHS endXXX does not match previous startXXX
> > junk at end of %<#pragma%> ghs section
> > malformed %<#pragma%> ghs section
> > and so on
> 
> Should be %<#pragma GHS endXXX%> (only 3 X, not 4 X), as well as
> %.
> 
> Looks like a fallout from enclosing keywords in quotes, missed in the manual
> review.

indeed; Martin L was last to touch in 62fcdefb (a -Wformat-diag fix)

(that's it for the config subdirectory, so I'm taking a break again)

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[andrew at sifive dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Waterman  ---
Correction: Appendix A recommends lr.w.aqrl + sc.w.rl.
https://github.com/riscv/riscv-isa-manual/blob/9ec8c0105dbf1492b57f6cafdb90a268628f476a/src/memory.tex#L1150-L1152

On Mon, Mar 7, 2022 at 3:51 PM Andrew Waterman  wrote:
>
> Appendix A of the RISC-V ISA manual says that lr.w.aq + sc.w.aqrl
> should suffice.  I see the patch puts aqrl on both the load and store,
> which, while correct, appears to be stronger than necessary.
>
> (cc Dan Lustig)
>
>
> On Mon, Mar 7, 2022 at 3:25 PM patrick at rivosinc dot com via
> Gcc-bugs  wrote:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
> >
> > Bug ID: 104831
> >Summary: RISCV libatomic LR.aq/SC.rl pair insufficient for
> > SEQ_CST
> >Product: gcc
> >Version: 12.0
> > Status: UNCONFIRMED
> >   Severity: normal
> >   Priority: P3
> >  Component: target
> >   Assignee: unassigned at gcc dot gnu.org
> >   Reporter: patrick at rivosinc dot com
> >   Target Milestone: ---
> >
> > Currently, libatomic's _sync_fetch_and_#op# and
> > __sync_val_compare_and_swap methods are not sufficiently strong for the
> > ATOMIC_SEQ_CST memory model.
> >
> > This can be shown using the following herd litmus test:
> > RISCV LRSC-LIB-CALL
> >
> > (*
> >   Current LR/SC pair as implemented in libatomic library call
> > *)
> >
> > {
> > 0:x6=a; 0:x8=b; 0:x10=c;
> > 1:x6=a; 1:x8=b; 1:x10=c;
> > }
> >
> >  P0  | P1   ;
> >  ori x1,x0,1 | lw x9,0(x10) ;
> >  sw x1,0(x10)| fence rw,rw  ;
> >  lr.w.aq x7,0(x8)| lw x5,0(x6)  ;
> >  ori x7,x0,1 |  ;
> >  sc.w.rl x3,x7,0(x8) |  ;
> >  sw x1,0(x6) |  ;
> >
> > ~exists (1:x9=1 /\ 1:x5=0 /\ b=1)

Re: [Bug target/104831] New: RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[Andrew Waterman]

Correction: Appendix A recommends lr.w.aqrl + sc.w.rl.
https://github.com/riscv/riscv-isa-manual/blob/9ec8c0105dbf1492b57f6cafdb90a268628f476a/src/memory.tex#L1150-L1152

On Mon, Mar 7, 2022 at 3:51 PM Andrew Waterman  wrote:
>
> Appendix A of the RISC-V ISA manual says that lr.w.aq + sc.w.aqrl
> should suffice.  I see the patch puts aqrl on both the load and store,
> which, while correct, appears to be stronger than necessary.
>
> (cc Dan Lustig)
>
>
> On Mon, Mar 7, 2022 at 3:25 PM patrick at rivosinc dot com via
> Gcc-bugs  wrote:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
> >
> > Bug ID: 104831
> >Summary: RISCV libatomic LR.aq/SC.rl pair insufficient for
> > SEQ_CST
> >Product: gcc
> >Version: 12.0
> > Status: UNCONFIRMED
> >   Severity: normal
> >   Priority: P3
> >  Component: target
> >   Assignee: unassigned at gcc dot gnu.org
> >   Reporter: patrick at rivosinc dot com
> >   Target Milestone: ---
> >
> > Currently, libatomic's _sync_fetch_and_#op# and
> > __sync_val_compare_and_swap methods are not sufficiently strong for the
> > ATOMIC_SEQ_CST memory model.
> >
> > This can be shown using the following herd litmus test:
> > RISCV LRSC-LIB-CALL
> >
> > (*
> >   Current LR/SC pair as implemented in libatomic library call
> > *)
> >
> > {
> > 0:x6=a; 0:x8=b; 0:x10=c;
> > 1:x6=a; 1:x8=b; 1:x10=c;
> > }
> >
> >  P0  | P1   ;
> >  ori x1,x0,1 | lw x9,0(x10) ;
> >  sw x1,0(x10)| fence rw,rw  ;
> >  lr.w.aq x7,0(x8)| lw x5,0(x6)  ;
> >  ori x7,x0,1 |  ;
> >  sc.w.rl x3,x7,0(x8) |  ;
> >  sw x1,0(x6) |  ;
> >
> > ~exists (1:x9=1 /\ 1:x5=0 /\ b=1)

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[andrew at sifive dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Waterman  ---
Appendix A of the RISC-V ISA manual says that lr.w.aq + sc.w.aqrl
should suffice.  I see the patch puts aqrl on both the load and store,
which, while correct, appears to be stronger than necessary.

(cc Dan Lustig)


On Mon, Mar 7, 2022 at 3:25 PM patrick at rivosinc dot com via
Gcc-bugs  wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
>
> Bug ID: 104831
>Summary: RISCV libatomic LR.aq/SC.rl pair insufficient for
> SEQ_CST
>Product: gcc
>Version: 12.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: target
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: patrick at rivosinc dot com
>   Target Milestone: ---
>
> Currently, libatomic's _sync_fetch_and_#op# and
> __sync_val_compare_and_swap methods are not sufficiently strong for the
> ATOMIC_SEQ_CST memory model.
>
> This can be shown using the following herd litmus test:
> RISCV LRSC-LIB-CALL
>
> (*
>   Current LR/SC pair as implemented in libatomic library call
> *)
>
> {
> 0:x6=a; 0:x8=b; 0:x10=c;
> 1:x6=a; 1:x8=b; 1:x10=c;
> }
>
>  P0  | P1   ;
>  ori x1,x0,1 | lw x9,0(x10) ;
>  sw x1,0(x10)| fence rw,rw  ;
>  lr.w.aq x7,0(x8)| lw x5,0(x6)  ;
>  ori x7,x0,1 |  ;
>  sc.w.rl x3,x7,0(x8) |  ;
>  sw x1,0(x6) |  ;
>
> ~exists (1:x9=1 /\ 1:x5=0 /\ b=1)

Re: [Bug target/104831] New: RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[Andrew Waterman]

Appendix A of the RISC-V ISA manual says that lr.w.aq + sc.w.aqrl
should suffice.  I see the patch puts aqrl on both the load and store,
which, while correct, appears to be stronger than necessary.

(cc Dan Lustig)


On Mon, Mar 7, 2022 at 3:25 PM patrick at rivosinc dot com via
Gcc-bugs  wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
>
> Bug ID: 104831
>Summary: RISCV libatomic LR.aq/SC.rl pair insufficient for
> SEQ_CST
>Product: gcc
>Version: 12.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: target
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: patrick at rivosinc dot com
>   Target Milestone: ---
>
> Currently, libatomic's _sync_fetch_and_#op# and
> __sync_val_compare_and_swap methods are not sufficiently strong for the
> ATOMIC_SEQ_CST memory model.
>
> This can be shown using the following herd litmus test:
> RISCV LRSC-LIB-CALL
>
> (*
>   Current LR/SC pair as implemented in libatomic library call
> *)
>
> {
> 0:x6=a; 0:x8=b; 0:x10=c;
> 1:x6=a; 1:x8=b; 1:x10=c;
> }
>
>  P0  | P1   ;
>  ori x1,x0,1 | lw x9,0(x10) ;
>  sw x1,0(x10)| fence rw,rw  ;
>  lr.w.aq x7,0(x8)| lw x5,0(x6)  ;
>  ori x7,x0,1 |  ;
>  sc.w.rl x3,x7,0(x8) |  ;
>  sw x1,0(x6) |  ;
>
> ~exists (1:x9=1 /\ 1:x5=0 /\ b=1)

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #2 from Patrick O'Neill  ---
Created attachment 52577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52577&action=edit
Patch v1

Patch submitted to mailing list.

Subject: [PATCH] RISCV: Strengthen libatomic lrsc pairs

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

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

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

--- Comment #1 from palmer at gcc dot gnu.org ---
I'm not quite sure what the rules on targeting 12 for this one: it's not
technically a regression, as it's always been broken, but it is a bug.  I'd err
on the side of taking a fix, as we're just strengthening the GCC implementation
so it should be pretty safe.  That said, anything related to memory models has
the potential for complicated fallout so I could understand wanting to wait
just to play it safe.

Patrick has a patch in progress.

[Bug tree-optimization/104746] False positive for -Wformat-overflow=2 since r12-7033-g3c9f762ad02f398c

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

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

--- Comment #9 from Martin Sebor  ---
Martin, since the warning is working correctly (even if it's arguably not as
clear as it could be), I'd like us to close this.  If you agree, can you please
go ahead and mark this as resolved (either invalid or wontfix)?

[Bug c++/104618] [12 Regression] trunk 20220221 on x86_64-linux-gnu ICEs building sh.cc for sh4-linux-gnu (in build_call_a, at cp/call.cc:381)

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:03e0c807ef50684cc1d49144948aa409decb91f9

commit r12-7528-g03e0c807ef50684cc1d49144948aa409decb91f9
Author: Jason Merrill 
Date:   Mon Feb 28 12:05:34 2022 -0400

c++: tweak to (*(fn))() patch [PR104618]

Other callers of mark_single_function might also want to look through these
wrapapers.

PR c++/104618

gcc/cp/ChangeLog:

* decl2.cc (mark_single_function): Look through parens and location
wrapper.
* typeck.cc (cp_build_addr_expr_1): Not here.

[Bug target/104831] New: RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 104831
   Summary: RISCV libatomic LR.aq/SC.rl pair insufficient for
SEQ_CST
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Currently, libatomic's _sync_fetch_and_#op# and 
__sync_val_compare_and_swap methods are not sufficiently strong for the
ATOMIC_SEQ_CST memory model.

This can be shown using the following herd litmus test:
RISCV LRSC-LIB-CALL

(* 
  Current LR/SC pair as implemented in libatomic library call
*)

{
0:x6=a; 0:x8=b; 0:x10=c;
1:x6=a; 1:x8=b; 1:x10=c;
}

 P0  | P1   ;
 ori x1,x0,1 | lw x9,0(x10) ;
 sw x1,0(x10)| fence rw,rw  ;
 lr.w.aq x7,0(x8)| lw x5,0(x6)  ;
 ori x7,x0,1 |  ;
 sc.w.rl x3,x7,0(x8) |  ;
 sw x1,0(x6) |  ;

~exists (1:x9=1 /\ 1:x5=0 /\ b=1)

[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy

[rangel_fischer at yahoo dot com.br via Gcc-bugs]

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

--- Comment #6 from Rangel Moreira Fischer  
---
When Compiler Optimization Level: Debug(-Og).
Compile OK.

When Compiler Optimization Level: Optimize for performance(-O2).
Compile Error.

[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy

[rangel_fischer at yahoo dot com.br via Gcc-bugs]

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

--- Comment #5 from Rangel Moreira Fischer  
---
I am using esp-idf sdk. I think gcc version is 8.4.0.

[Bug libstdc++/104807] [12 Regression] x86_64-w64-mingw32 target does not have visibility setting

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mckelvey at maskull dot com

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

[Bug libstdc++/104830] Errors Building gcc-12-20220306 under Cygwin: __terminate and more

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 104807, just fixed earlier today.

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

[Bug libstdc++/104830] Errors Building gcc-12-20220306 under Cygwin: __terminate and more

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #1 from James McKelvey  ---
Created attachment 52576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52576&action=edit
Config log

[Bug libstdc++/104830] New: Errors Building gcc-12-20220306 under Cygwin: __terminate and more

[mckelvey at maskull dot com via Gcc-bugs]

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

Bug ID: 104830
   Summary: Errors Building gcc-12-20220306 under Cygwin:
__terminate and more
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 52575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52575&action=edit
Complete build log

Up-to-date Cygwin CYGWIN_NT-10.0 under Windows 10.

Using gcc-11-20220305

 ./configure --enable-languages=c,c++ --enable-threads=posix

...
/home/McKelvey/gcc-12-20220306/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc
-B/home/McKelvey/gcc-12-20220306/host-x86_64-pc-cygwin/gcc -nostdinc++
-L/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/src
-L/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/src/.libs
-L/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem
/usr/local/x86_64-pc-cygwin/include -isystem
/usr/local/x86_64-pc-cygwin/sys-include   -fno-checking -x c++-header
-nostdinc++ -g -O2 
-I/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin
-I/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include
-I/home/McKelvey/gcc-12-20220306/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/home/McKelvey/gcc-12-20220306/libstdc++-v3/include/precompiled/stdc++.h \
-o x86_64-pc-cygwin/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/cassert:43,
 from
/home/McKelvey/gcc-12-20220306/libstdc++-v3/include/precompiled/stdc++.h:33:
/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin/bits/c++config.h:308:3:
error: expected constructor, destructor, or type conversion before ‘(’ token
  308 |   _GLIBCXX_VISIBILITY(default)
  |   ^~~
In file included from
/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/future:49,
 from
/home/McKelvey/gcc-12-20220306/libstdc++-v3/include/precompiled/stdc++.h:105:
/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/bits/std_thread.h:
In destructor ‘std::thread::~thread()’:
/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/bits/std_thread.h:151:14:
error: ‘__terminate’ is not a member of ‘std’; did you mean ‘terminate’?
  151 | std::__terminate();
  |  ^~~
  |  terminate
/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/bits/std_thread.h:
In member function ‘std::thread& std::thread::operator=(std::thread&&)’:
/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include/bits/std_thread.h:164:14:
error: ‘__terminate’ is not a member of ‘std’; did you mean ‘terminate’?
  164 | std::__terminate();
  |  ^~~
  |  terminate
make[5]: *** [Makefile:1888: x86_64-pc-cygwin/bits/stdc++.h.gch/O2ggnu++0x.gch]
Error 1
make[5]: Leaving directory
'/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3/include'
make[4]: *** [Makefile:576: all-recursive] Error 1
make[4]: Leaving directory
'/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3'
make[3]: *** [Makefile:501: all] Error 2
make[3]: Leaving directory
'/home/McKelvey/gcc-12-20220306/x86_64-pc-cygwin/libstdc++-v3'
make[2]: *** [Makefile:18277: all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/home/McKelvey/gcc-12-20220306'
make[1]: *** [Makefile:23994: stage1-bubble] Error 2
make[1]: Leaving directory '/home/McKelvey/gcc-12-20220306'
make: *** [Makefile:1072: all] Error 2

McKelvey@DESKTOP-DQ97FGL ~/gcc-12-20220306

[Bug fortran/104811] maxloc/minloc cannot accept character arguments without `dim` optional argument.

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Note that gcc-8 to gcc-10 ICE on the testcase, and gcc-7 rejects character
array arguments (which is a F2003 feature).

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Pure 32-bit PowerPC build   |[12 Regression] Pure 32-bit
   |broken  |PowerPC build broken
   Target Milestone|--- |12.0

[Bug target/104829] Pure 32-bit PowerPC build broken

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target||powerpc-linux
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
   Priority|P3  |P1

[Bug target/104829] New: Pure 32-bit PowerPC build broken

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

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

Bug ID: 104829
   Summary: Pure 32-bit PowerPC build broken
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

In  Joseph
reports that I have broken the default build for powerpc-linux.  Whoops.

[Bug fortran/104811] maxloc/minloc cannot accept character arguments without `dim` optional argument.

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2022-03-07

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Compiles and executes without optimization or if -fno-frontend-optimize is
> used with optimization.

Good observation.

The inline expansion that may be helpful for integer and real arguments
will not even be done in trans-intrinsic.cc, as the following comment
explains:

  /* Special case for character maxloc.  Remove unneeded actual
 arguments, then call a library function.  */

The obvious solution is to punt on character array arguments:

diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 4033f27df99..5eba6345145 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -2276,6 +2276,7 @@ optimize_minmaxloc (gfc_expr **e)
   if (fn->rank != 1
   || fn->value.function.actual == NULL
   || fn->value.function.actual->expr == NULL
+  || fn->value.function.actual->expr->ts.type == BT_CHARACTER
   || fn->value.function.actual->expr->rank != 1)
 return;

[Bug tree-optimization/101956] Miss vectorization from v4hi to v4df

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/101909] [12 Regression] 73% regression on tfft benchmark for -O2 -ftree-loop-vectorize compared to -O2 on zen hardware

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|73% regression on tfft  |[12 Regression] 73%
   |benchmark for -O2   |regression on tfft
   |-ftree-loop-vectorize   |benchmark for -O2
   |compared to -O2 on zen  |-ftree-loop-vectorize
   |hardware|compared to -O2 on zen
   ||hardware

[Bug tree-optimization/101910] [12 Regression] tsvc regressions for -O2 -ftree-loop-vectorize at zen hardware

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|tsvc regressions for -O2|[12 Regression] tsvc
   |-ftree-loop-vectorize at|regressions for -O2
   |zen hardware|-ftree-loop-vectorize at
   ||zen hardware
   Target Milestone|--- |12.0

[Bug fortran/99585] ICE with SIZE intrinsic on nested derived type components

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r12-7526-gc0134b7383992aab5c1a91440dbdd8fbb747169c
Author: Tobias Burnus 
Date:   Mon Mar 7 22:11:33 2022 +0100

Fortran: Fix gfc_maybe_dereference_var [PR104430][PR99585]

PR fortran/99585
PR fortran/104430

gcc/fortran/ChangeLog:

* trans-expr.cc (conv_parent_component_references): Fix comment;
simplify comparison.
(gfc_maybe_dereference_var): Avoid d referencing a nonpointer.

gcc/testsuite/ChangeLog:

* gfortran.dg/class_result_10.f90: New test.

[Bug fortran/104430] [9/10/11/12 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742 since r9-3522-gd0477233215e37de

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r12-7526-gc0134b7383992aab5c1a91440dbdd8fbb747169c
Author: Tobias Burnus 
Date:   Mon Mar 7 22:11:33 2022 +0100

Fortran: Fix gfc_maybe_dereference_var [PR104430][PR99585]

PR fortran/99585
PR fortran/104430

gcc/fortran/ChangeLog:

* trans-expr.cc (conv_parent_component_references): Fix comment;
simplify comparison.
(gfc_maybe_dereference_var): Avoid d referencing a nonpointer.

gcc/testsuite/ChangeLog:

* gfortran.dg/class_result_10.f90: New test.

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[goswin-v-b at web dot de via Gcc-bugs]

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

--- Comment #29 from Goswin von Brederlow  ---
(In reply to Jakub Jelinek from comment #26)

> That is nonsense.  The amount of code in the wild that relies on (type
> *)CONSTANT
> working is insane, you can't annotate it all.  And it has worked fine for
> decades.  The pointers aren't invalid, they point to valid objects in the
> address space.
> POSIX supports MAP_FIXED for a reason (and in many embedded cases one
> doesn't even have an MMU and I/O or other special areas are mapped directly).

A cast from integer to pointer is implementation defined behavior except for

1) 0 which must cast to NULL / nullptr
2) if the integer value was constructed by casting a pointer to integer of
suitable size

There is no garantee in the C standard that '(type *)CONSTANT' will actually
point to the hardware address 'CONSTANT'. It's just how gcc happens to do it in
most cases. So no, your code is not fine. It is fragile. It relies on
implementation details of gcc. But lets not argue about that.


Detecting NULL pointer access and offsets to it is a good thing, except where
it isn't. It's unfortunate it also catches other stuff. Under AmigaOS the
pointer to the exec.library (no program can work without that) is stored in
address 4. So there isn't an universal value of "this is big enough not to be
an offset to NULL".

Detecting if an expression involves NULL might be hard. If it starts as
NULL->member then it's easy. What about (&x - &x)+offsetof(X.member) or
(uintptr_t)&x.member - (uintptr_t)&x or similar stuff you easily get with
macros. On the other side (T*)0x45634534 should be easy to detect as not being
NULL+offset. It's a literal. But the grey zone inbetween the easy cases might
be to big to be useful.

Alternatively an annotation for this would actually go nicely with another bug
I reported: 'add feature to create a pointer to a fixed address as constexpr'
[1].  The annotation would avoid the warning and also make it a pointer literal
that can be used in constexpr (appart from accessing the address). It could
also cause gcc to handle the case where CONSTANT can't just be cast to pointer
and work. Like when using address authentication on ARMv8 CPUs, to name
something modern.

And the size of the object the pointer points to can be taken from its type,
i.e. the pointer is to a single object and never an (infinite) array. If you
want a pointer to an array then cast it to an array of the right size.

--
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104514

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

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

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

--- Comment #30 from Segher Boessenkool  ---
There should be a __SIZEOF_IEEE128__ as well, of course.

[Bug c++/102209] NRVO for function parameters

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/103460] GCC rejected operator[](auto[]...) after P2128

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.
P2128R6 says:
We propose that operator[] should be able to accept zero or more arguments,
including variadic arguments. 

Interesting how clang also rejects this.

Simplified testcase to understand the issue:
struct S {
  void operator[](int,...);
};

--- CUT 
"auto[]..." is the same as "auto[]," really.

As far as I read the paper, it is clear this should be accepted unless I really
miss something.

[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code

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

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

--- Comment #16 from Segher Boessenkool  ---
There are many patterns that use VEC_I, and not all have a V1TI variant
currently, so adding V1TI to it is not suitable for now.  It is better to
add a new iterator for now.

This whole thing desperately needs a big cleanup :-(

[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy

[rangel_fischer at yahoo dot com.br via Gcc-bugs]

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

Rangel Moreira Fischer  changed:

   What|Removed |Added

 CC||rangel_fischer at yahoo dot 
com.br

--- Comment #4 from Rangel Moreira Fischer  
---
Same problem too.

static void write_my_message( char* message, size_t max_message_size, char*
my_message )
{
size_t messag_len = strlen(my_message) + 1;

if( messag_len > max_message_size )
{
// trunc message
strncpy(message, my_message, max_message_size - 1);  // ex:
max_message_size = max buf size = 50(0 to 49). 0 to 48 = 49
elements(max_message_size - 1). 
message[max_message_size - 1] = '\0';  // message[50-1] = message[49] =
'\0'.
}
else
{
strncpy(message, my_message, messag_len);
} 
}


In function 'write_my_message':

error: 'strncpy' specified bound depends on the length of the source argument
[-Werror=stringop-overflow=]

strncpy(message, my_message, messag_len);
^~~~

note: length computed here
size_t messag_len = strlen(my_message) + 1;
^~

[Bug libstdc++/104807] [12 Regression] x86_64-w64-mingw32 target does not have visibility setting

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
.

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||goswin-v-b at web dot de

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

[Bug tree-optimization/104828] Wrong out-of-bounds array access warning on literal pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 99578.

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

[Bug analyzer/101983] analyzer leak false positives building singly linked list

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
As noted above, these appear to be true positives.  The above patch fixes the
issue with detection of "main"; the remaining issue is the use of ,
which I'm tracking in PR analyzer/99771.

Marking this as resolved.

[Bug c/104828] New: Wrong out-of-bounds array access warning on literal pointers

[goswin-v-b at web dot de via Gcc-bugs]

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

Bug ID: 104828
   Summary: Wrong out-of-bounds array access warning on literal
pointers
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goswin-v-b at web dot de
  Target Milestone: ---

Trying to access a pointer cast from an integer literal gives a out of bounds
warning:

--
#define UART0_BASE  0x3F201000
void putc(char c) {
  volatile unsigned int *UART0_DR = (volatile unsigned int *)(UART0_BASE);
  volatile unsigned int *UART0_FR = (volatile unsigned int *)(UART0_BASE +
0x18);
  while (*UART0_FR & (1 << 5) ) { }
  *UART0_DR = c;
}
--

:5:3: warning: array subscript 0 is outside array bounds of 'volatile
unsigned int [0]' [-Warray-bounds]
5 |   *UART0_DR = c;
  |   ^

The error goes away if the pointer is global or static.

The error remains if the pointer is returned from a function with alloc_size
attribute:

--
#include 
#include 

#define UART0_BASE  0x3F201000

volatile uint32_t * make(uintptr_t addr, size_t size = 4) __attribute__
((alloc_size (2)));
volatile uint32_t * make(uintptr_t addr, size_t size) {
(void)size;
return (volatile uint32_t *)addr;
}

void putc(char c) {
  volatile uint32_t *UART0_DR = make(UART0_BASE);
  volatile uint32_t *UART0_FR = make(UART0_BASE + 0x18);
  while (*UART0_FR & (1 << 5) ) { }
  *UART0_DR = c;
}
--

:16:3: warning: array subscript 0 is outside array bounds of 'volatile
uint32_t [0]' [-Warray-bounds]
   16 |   *UART0_DR = c;
  |   ^

The warning goes away if the "make" helper is extern and can't be inlined.

Gcc 11.2 and before do not give this warning.

[Bug analyzer/101983] analyzer leak false positives building singly linked list

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-7525-g0af37ad4422052be4b7f779737e14c80e57d0ad9
Author: David Malcolm 
Date:   Mon Mar 7 14:19:30 2022 -0500

analyzer: fix leak suppression at end of 'main' [PR101983]

PR analyzer/101983 reports what I thought were false positives
from -Wanalyzer-malloc-leak, but on closer inspection, the
analyzer is correctly reporting heap-allocated buffers that are
no longer reachable.

However, these "leaks" occur at the end of "main".  The analyzer already
has some logic to avoid reporting leaks at the end of main, where the
leak is detected at the end of the EXIT basic block.  However, in this
case,
the leak is detected at the clobber in BB 2 here:
   :
  func (&res);
  res ={v} {CLOBBER(eol)};
  _4 = 0;

   :
:
  return _4;

where we have a chain BB 2 -> BB 3 -> EXIT BB.

This patch generalizes the "are we at the end of 'main'" detection to
handle such cases, silencing -Wanalyzer-malloc-leak on them.

There's a remaining issue where the analyzer unhelpfully describes one
of the leaking values as '', rather than 'res.a', but I'm
leaving that for a followup (covered by PR analyzer/99771).

gcc/analyzer/ChangeLog:
PR analyzer/101983
* engine.cc (returning_from_function_p): New.
(impl_region_model_context::on_state_leak): Use it when rejecting
leaks at the return from "main".

gcc/testsuite/ChangeLog:
PR analyzer/101983
* gcc.dg/analyzer/pr101983-main.c: New test.
* gcc.dg/analyzer/pr101983-not-main.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/99771] Analyzer diagnostics should not say ""

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-7525-g0af37ad4422052be4b7f779737e14c80e57d0ad9
Author: David Malcolm 
Date:   Mon Mar 7 14:19:30 2022 -0500

analyzer: fix leak suppression at end of 'main' [PR101983]

PR analyzer/101983 reports what I thought were false positives
from -Wanalyzer-malloc-leak, but on closer inspection, the
analyzer is correctly reporting heap-allocated buffers that are
no longer reachable.

However, these "leaks" occur at the end of "main".  The analyzer already
has some logic to avoid reporting leaks at the end of main, where the
leak is detected at the end of the EXIT basic block.  However, in this
case,
the leak is detected at the clobber in BB 2 here:
   :
  func (&res);
  res ={v} {CLOBBER(eol)};
  _4 = 0;

   :
:
  return _4;

where we have a chain BB 2 -> BB 3 -> EXIT BB.

This patch generalizes the "are we at the end of 'main'" detection to
handle such cases, silencing -Wanalyzer-malloc-leak on them.

There's a remaining issue where the analyzer unhelpfully describes one
of the leaking values as '', rather than 'res.a', but I'm
leaving that for a followup (covered by PR analyzer/99771).

gcc/analyzer/ChangeLog:
PR analyzer/101983
* engine.cc (returning_from_function_p): New.
(impl_region_model_context::on_state_leak): Use it when rejecting
leaks at the return from "main".

gcc/testsuite/ChangeLog:
PR analyzer/101983
* gcc.dg/analyzer/pr101983-main.c: New test.
* gcc.dg/analyzer/pr101983-not-main.c: New test.

Signed-off-by: David Malcolm 

[Bug c/96249] The string " bytes" is repeated at the end of the message

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

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

Eric Gallager  changed:

   What|Removed |Added

 Depends on|40883   |
 CC||egallager at gcc dot gnu.org
 Blocks||40883

--- Comment #3 from Eric Gallager  ---
reminder that when a bug falls under the umbrella of a meta-bug, the meta-bug
goes in the "Blocks" field, not the "Depends on" field


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

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

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104794
 CC||iains at gcc dot gnu.org,
   ||prathamesh3492 at gcc dot 
gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #28 from Eric Gallager  ---
(In reply to Roland Illig from comment #9)
> From config/host-darwin.cc:
> > error ("PCH memory not available %m");
> 
> Looks like a missing ":" before "%m".

Iain Sandoe's string (22a98240)

(In reply to Roland Illig from comment #10)
> From aarch64-sve-builtins.cc:
> > error_at (location, "passing single vector %qT to argument %d"
> >   " of %qE, which expects a tuple of %d vectors",
> >   actual, argno + 1, fndecl, num_vectors);
> 
> "%d vectors" must use the correct plural form, for the benefit of Polish,
> Russian, Arabic and several more.

Richard Sandiford's string (624d0f07)

(In reply to Roland Illig from comment #11)
> From aarch64-sve-builtins.cc:
> > passing %qT to argument %d of %qE, which expects a scalar integer
> 
> "scalar integer" sounds redundant, this may be a copy-and-paste mistake from
> the message directly above, which says "scalar element".

Likewise.

(In reply to Roland Illig from comment #12)
> From aarch64-sve-builtins.cc:
> > "capture by copy of SVE type %qT"
> 
> This message should use the same grammar as the related ones, the word
> "cannot" is a useful indicator of the general error condition.

Same author, different commit (02a32ab4)

(In reply to Roland Illig from comment #13)
> From aarch64.cc:
> > invalid feature modifier %s
> 
> The %s must be %qs, like in the related messages.

Looks like Martin L was the last one to touch it (in 03a1a86b, which,
ironically, was a -Wformat-diag fix)

(In reply to Roland Illig from comment #14)
> From aarch64.cc:
> > "invalid name (%qs) in % pragma or attribute"
> 
> What is the point of having parentheses around %qs? That seems redundant to
> me.

Likewise.

(In reply to Roland Illig from comment #15)
> From aarch64.cc:
> > arch extension %<%s%>
> 
> Use the idiomatic %qs instead.

Prathamesh's string (145be5ef)

(In reply to Roland Illig from comment #16)
> From arm-builtins.cc:
> > "the range of count should be in 0 to 32;
> > please check the intrinsic %<_mm_rori_pi16%> in code"
> 
> Please double-check whether the "0 to 32" is a typo and should rather be "0
> to 16". That would match the "0 to 64" for _mm_rori_si64 a few lines further
> down.

I think this was covered by bug 104794

(taking a break again)

[Bug tree-optimization/104789] [12 Regression] -Wstringop-overflow false positive at -O3 for an unrolled loop

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

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

--- Comment #9 from Martin Sebor  ---
A much simplified test case that reproduces the same warning (with both GCC 12
and 11) is below.  The underlying problem is that although GCC does have a way
to represent simple disjoint ranges of variable values, it's not used here, and
even if it were, very little code makes uses of this representation beyond a
single contiguous range (or, at most, a converse of it).  Even the disjoint
representation isn't sufficiently flexible to capture arbitrarily complex
ranges (capturing those in their full generality would require a constraint
solver).

$ cat z.c && gcc -O3 -S -Wall z.c
char a[8];

void f (unsigned n)
{
  unsigned i = 0;

  for (unsigned j = 0; i != n; ++j)
i += 2;

  if (i > 7)
return;

  while (i % 4)
a[i++] = 0;
}
z.c: In function ‘f’:
z.c:14:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   14 | a[i++] = 0;
  | ~~~^~~
z.c:1:6: note: at offset 8 into destination object ‘a’ of size 8
1 | char a[8];
  |  ^

The warning can be avoided (and the emitted object code improved) by changing
the while loop like so:

  while (i % 4)
{
  if (i > 7) __builtin_unreachable (); 
  a[i++] = 0;
}

The same suppression works in the test case in comment #7 but GCC then issues
another warning, this one pointing out that an element of the header array is
used uninitialized.  That warning looks valid to me:

/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:61,
 from pr104789.C:2:
In member function ‘void std::__new_allocator<_Tp>::construct(_Up*, _Args&&
...) [with _Up = unsigned char; _Args = {const unsigned char&}; _Tp = unsigned
char]’,
inlined from ‘static void std::allocator_traits
>::construct(allocator_type&, _Up*, _Args&& ...) [with _Up = unsigned char;
_Args = {const unsigned char&}; _Tp = unsigned char]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:516:17,
inlined from ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&)
[with _Tp = unsigned char; _Alloc = std::allocator]’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1280:30,
inlined from ‘void commit_temp_packets()’ at pr104789.C:37:17:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/new_allocator.h:175:11:
warning: ‘header’ may be used uninitialized [-Wmaybe-uninitialized]
  175 | { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
  |   ^~
pr104789.C: In function ‘void commit_temp_packets()’:
pr104789.C:10:17: note: ‘header’ declared here
   10 | uint8_t header[8];
  | ^~

[Bug tree-optimization/104789] [12 Regression] New -Wstringop-overflow false positive since r12-5863-g9354a7d70caef1c9

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

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

--- Comment #8 from Martin Sebor  ---
Created attachment 52574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52574&action=edit
Output of debug_ranger() for the affected function.

The IL the first warning triggers for in the test case in comment #7 is below. 
The access to header[header_bytes_152] where header_bytes_152's value is in [8,
8][10, 10] is out of bounds for unsigned char[8].  So the warning is correctly
pointing out the invalid store.  The store is the result of GCC unrolling the
first six iterations of the while loop, starting with index 4 (stores at index
2 and 3 are hoisted above the unrolled loop).  The last two iterations store
past the end of the header array.  GCC 11 also unrolls six iterations of the
loop but it starts with index 2 (it doesn't hoist the first two stores above
it).  The attachment shows the full output of calling debug_ranger() on the
function.

=== BB 13 
Imports: header_bytes_192  
Exports: _147  header_bytes_152  header_bytes_192  
 _147 : header_bytes_152  header_bytes_192(I)  
 header_bytes_152 : header_bytes_192(I)  
header_bytes_192unsigned int [4, 4][6, 6]
Relational : (header_bytes_152 > header_bytes_192)
 [local count: 21246984]:
header_bytes_152 = header_bytes_192 + 4;
header[header_bytes_65] = 0;
_147 = header_bytes_152 & 3;
if (_147 != 0)
  goto ; [85.71%]
else
  goto ; [14.29%]

_147 : unsigned int [0, 0][2, 2]
header_bytes_152 : uint32_t [8, 8][10, 10]
13->14  (T) _147 :  unsigned int [2, 2]
13->14  (T) header_bytes_152 :  uint32_t [8, 8][10, 10]
13->14  (T) header_bytes_192 :  unsigned int [4, 4][6, 6]
13->20  (F) _147 :  unsigned int [0, 0]
13->20  (F) header_bytes_152 :  uint32_t [8, 8][10, 10]
13->20  (F) header_bytes_192 :  unsigned int [4, 4][6, 6]

=== BB 14 
Imports: header_bytes_192  
Exports: _131  header_bytes_133  header_bytes_192  
 _131 : header_bytes_133  header_bytes_192(I)  
 header_bytes_133 : header_bytes_192(I)  
header_bytes_192unsigned int [4, 4][6, 6]
Relational : (header_bytes_133 > header_bytes_192)
 [local count: 18210790]:
header_bytes_133 = header_bytes_192 + 5;
header[header_bytes_152] = 0;<<< -Wstringop-overflow
_131 = header_bytes_133 & 3;
if (_131 != 0)
  goto ; [85.71%]
else
  goto ; [14.29%]

_131 : unsigned int [1, 1][3, 3]
header_bytes_133 : uint32_t [9, 9][11, 11]
14->15  (T) _131 :  unsigned int [1, 1][3, 3]
14->15  (T) header_bytes_133 :  uint32_t [9, 9][11, 11]
14->15  (T) header_bytes_192 :  unsigned int [4, 4][6, 6]
14->21  (F) _131 :  UNDEFINED
14->21  (F) header_bytes_133 :  UNDEFINED
14->21  (F) header_bytes_192 :  UNDEFINED

[Bug fortran/104827] New: [12 Regression] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.cc:8329

[gscfq--- via Gcc-bugs]

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

Bug ID: 104827
   Summary: [12 Regression] ICE in
gfc_conv_array_constructor_expr, at
fortran/trans-expr.cc:8329
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211010 and 20211017 :


$ cat z1.f90
program p
   !$omp declare variant(a) match(implementation={f([1])})
end


$ cat z2.f90
program p
   !$omp declare variant(a) match(implementation={f(1)})
end


$ gfortran-12-20220306 -c z2.f90 -fopenmp
$
$ gfortran-12-20220306 -c z1.f90 -fopenmp
z1.f90:1:9:

1 | program p
  | 1
internal compiler error: in gfc_conv_array_constructor_expr, at
fortran/trans-expr.cc:8329
0x7dab56 gfc_conv_array_constructor_expr
../../gcc/fortran/trans-expr.cc:8329
0x7dab56 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9422
0x8184a1 gfc_trans_omp_declare_variant(gfc_namespace*)
../../gcc/fortran/trans-openmp.cc:7641
0x7cce37 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.cc:3118
0x7d317e gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7471
0x754b0e translate_all_program_units
../../gcc/fortran/parse.cc:6651
0x754b0e gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x7a1edf gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

[Bug tree-optimization/104825] [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:840

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug fortran/104826] New: [11/12 Regression] ICE in gimple_range_global, at value-query.cc:424

[gscfq--- via Gcc-bugs]

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

Bug ID: 104826
   Summary: [11/12 Regression] ICE in gimple_range_global, at
value-query.cc:424
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20210606 and 20210613 :


$ cat z1.f90
program p
   character(:), allocatable :: x
   save
   !$omp target
   x = 'abc'
   !$omp end target
end


$ cat z2.f90   # no save
program p
   character(:), allocatable :: x
   !$omp target
   x = 'abc'
   !$omp end target
end


$ gfortran-12-20210606 -c z1.f90 -fopenmp
$ gfortran-12-20220213 -c z2.f90 -fopenmp
$
$ gfortran-12-20220213 -c z1.f90 -fopenmp
during GIMPLE pass: walloca
z1.f90:5:12:

5 |x = 'abc'
  |^
internal compiler error: Segmentation fault
0xccad7f crash_signal
../../gcc/toplev.cc:322
0xf5c9ec gimple_range_global(tree_node*)
../../gcc/value-query.cc:424
0x1864d80 ranger_cache::get_global_range(irange&, tree_node*) const
../../gcc/gimple-range-cache.cc:923
0x1860f8e gimple_ranger::export_global_ranges()
../../gcc/gimple-range.cc:474
0x189c0e1 pass_walloca::execute(function*)
../../gcc/gimple-ssa-warn-alloca.cc:381

[Bug c/104825] New: [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:840

[gscfq--- via Gcc-bugs]

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

Bug ID: 104825
   Summary: [12 Regression] ICE in ao_ref_init_from_ptr_and_range,
at tree-ssa-alias.cc:840
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211121 and 20211128, at -O1+ :


$ cat z1.c
#include 
int foo (fmt)
char* fmt;
{
  return (strchr (fmt, '*') != 0
  || strchr (fmt, 'n') != 0);
}
void bar ()
{
  if ( foo (1) )
__builtin_abort ();
}


$ gcc-12-20220306 -c z1.c
$
$ gcc-12-20220306 -c z1.c -O2
during GIMPLE pass: fre
z1.c: In function 'bar':
z1.c:12:1: internal compiler error: in ao_ref_init_from_ptr_and_range, at
tree-ssa-alias.cc:840
   12 | }
  | ^
0xcfa3f7 ao_ref_init_from_ptr_and_range(ao_ref*, tree_node*, bool, poly_int<1u,
long>, poly_int<1u, long>, poly_int<1u, long>)
../../gcc/tree-ssa-alias.cc:840
0xa0de1b modref_access_node::get_ao_ref(gcall const*, ao_ref*) const
../../gcc/ipa-modref-tree.cc:688
0xdc6283 visit_reference_op_call
../../gcc/tree-ssa-sccvn.cc:5143
0xdcfd58 visit_stmt
../../gcc/tree-ssa-sccvn.cc:5846
0xdd0aeb process_bb
../../gcc/tree-ssa-sccvn.cc:7481
0xdd25dd do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool,
vn_lookup_kind)
../../gcc/tree-ssa-sccvn.cc:7966
0xdd2f3b execute
../../gcc/tree-ssa-sccvn.cc:8232

[Bug middle-end/104800] reodering of potentially trapping operations and volatile stores

[paulmckrcu at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Paul McKenney  ---
(In reply to Richard Biener from comment #6)
> Generally GCCs middle-end considers volatile stores (or loads) to not have
> any side-effects that are not visible in the IL.  That includes (synchronous)
> raise of signals (and thus effects on control flow), effects on other
> (non-volatile) memory, etc.  If a volatile access has to be considered having
> an effect on control flow then the standard should explicitely mention that,
> I don't think it does that at the moment, it merely says those statements
> invoke "changes in the state of the execution environment"
> 
> So volatile "issues" like this are no different from issues that arise
> with respect to observability when you consider asynchronous events and
> the effect of re-ordering of statements.  In fact C17 especially notes
> that objects that are not volatile sig_atomic_t have unspecified value
> on such events, so that IMHO also covers generating a trap from a volatile
> access.
> 
> Volatile accesses are deemed observable but we do not re-order those, this
> bug is about re-ordering unrelated stmts with respect to such accesses.
> 
> I don't think the standard requires us to fix this reported behavior.
> 
> A mitigation in the middle-end requires volatile accesses to behave as
> possibly altering control flow.  That's iffy if they continue to be
> represented as simple assign statements, the closest would be to always
> mark them as possibly trapping (something we cannot do right now).
> 
> The PRE "fix" is just covering up a single place in the compiler that fails
> to consider volatile accesses as altering control flow.

Understood that normal accesses can be reordered with volatile accesses.  Cases
where this is a problem can prevent it, for example, using an asm with the
"memory" clobber.

The concern here is not the memory access, but the potential for trapping,
which in this case is the potential division by zero.

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com,
   ||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #27 from Eric Gallager  ---
(In reply to Roland Illig from comment #4)
> From common.opt:
> > an invalid linenum macros
> 
> "an" + "macros" doesn't match

Martin L's string (8bf728ae)

(In reply to Roland Illig from comment #7)
> From params.opt:
> > When propagating IPA-CP effect estimates, multiply frequencies of recursive
> > edges that that bring back an unchanged value by this factor.
> 
> "that that"
> 
> From params.opt:
> > Maximum combinaed size of caller and callee wich is inlined if callee
> > is called once.
> 
> "combined"
> "which"
> 
> From params.opt:
> > --param=ranger-debug=[none|trace|gori|cache|tracegori|all]
> > Specifies the output mode for debugging ranger.
> 
> Why " " instead of the usual "\t" after the "]"?

1. Martin Jambor's string (ff2b92de)
2. Jan Hubicka's string (f157c536)
3. Andrew MacLeod's string (9cb114fd)

(In reply to Roland Illig from comment #8)
> From tree-ssa-uninit.c:
> > accessing argument %u of a function declared with attribute %<%s%>
> 
> The %<%s%> should be the conventional %qs.

Martin Sebor's string (fb85d6eb)

(that's all I'm going to check the `git blame` for for now; might come back to
the rest later...)

[Bug c++/104823] [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075

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

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

--- Comment #2 from Patrick Palka  ---
r12-6075 is exposing a latent bug with non-dependent decltype folding, namely
we instantiate the expression only if it's potentially constant.  In this case,
id(v) is not potentially constant because id is not a constexpr function, so we
discard the expression without actually instantiating it and therefore never
issue the narrowing warning.

[Bug libstdc++/104824] New: std::comp_ellint1 handles domain error incorrectly

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

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

Bug ID: 104824
   Summary: std::comp_ellint1 handles domain error incorrectly
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The standard defines std::comp_ellint1 for |k| <= 1, but we do:

  else if (std::abs(__k) >= _Tp(1))
return std::numeric_limits<_Tp>::quiet_NaN();

This is the wrong condition, and is not the correct way to report the error.

Reporting a domain error should be done as specified by C:

"On a domain error, the function returns an implementation-defined value; if
the integer expression math_errhandling & MATH_ERRNO is nonzero, the integer
expression errno acquires the value EDOM; if the integer expression
math_errhandling & MATH_ERREXCEPT is nonzero, the “invalid” floating-point
exception is raised."

Other special functions throw std::domain_error, which isn't right either.

We should check all the domains, and fix the method of error reporting.

[Bug c++/104823] [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)

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

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

--- Comment #7 from Jakub Jelinek  ---
As A.3 is in the body of a construct that is outlined into a separate function,
it should be moved to the *omp_fn* function with it.
If you look at simple
int
main ()
{
  #pragma omp parallel
  {
int a = 25;
++a;
  }
}
you can see in the gimple dump two pairs of {}s instead of just once:
#pragma omp parallel
  {
{
  int a;

  a = 25;
  a = a + 1;
}
  }
(ditto target, task, (host) teams etc.), while with acc parallel that isn't the
case:
  #pragma omp target oacc_parallel map(from:(*array.12_5) [len: D.4276])
map(alloc:array [pointer assign, bias: 0]) firstprivate(ubound.0)
firstprivate(nn)
{
The reason for that for the OpenMP construct is exactly to ensure that
move_sese_region_to_fn does the right thing with it.

[Bug c++/104823] [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P2

[Bug c++/104823] [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-07

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug rtl-optimization/104814] [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Oh forgot to mention it is just: gcc -O1 t.c

Works fine with -O{0,2,3}

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=57943,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104823

--- Comment #14 from Patrick Palka  ---
Looks like the comment #11 and comment #12 testcases are fixed for GCC 11 by
r11-434.  But recently for GCC 12 we stopped diagnosing the narrowing
conversion in f5, I reported that as PR104823.

[Bug c++/104823] New: [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075

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

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

Bug ID: 104823
   Summary: [12 Regression] narrowing conversion inside
non-dependent decltype operand silently accepted ever
since r12-6075
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

struct S { S(int); };

int id(int v);
double id(double v);

template auto f(double v) -> decltype(S{id(v)});


GCC 11 correctly issues a narrowing conversion warning for this testcase ever
since r11-434:

:6:50: warning: narrowing conversion of ‘id(v)’ from ‘double’ to ‘int’
[-Wnarrowing]

But in GCC 12 the warning is gone.

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek  ---
Is this fixed now?

[Bug fortran/104812] Construct-name with same variable name in scope

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
gfortran is correct.  See Fortran 2018, 19.4, p 498.

   Identifiers of entities, other than statement or construct entities (19.4),
   in the classes

 (1) named variables, ..., named constructs, ...,


  Within its scope, a local identifier of one class shall not be the
  same as another local identifier of the same class,

[Bug debug/104778] [12 Regression] ICE in simplify_subreg, at simplify-rtx.cc:7324

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

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

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce at least with current trunk, both with gcc configured for
powerpc64-linux-gnu and additional -m32, or in a cross to
powerpc-e300c3-linux-gnu with the given options.

[Bug c++/104803] if consteval error from branch that isn't evaluated anyway

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
.

[Bug libstdc++/104807] [12 Regression] x86_64-w64-mingw32 target does not have visibility setting

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:4cb935cb69f12088975fa7f6907c6ace0580e2dd

commit r12-7522-g4cb935cb69f12088975fa7f6907c6ace0580e2dd
Author: Jonathan Wakely 
Date:   Mon Mar 7 15:07:05 2022 +

libstdc++: Use visibility pragmas instead of attributes [PR104807]

The _GLIBCXX_PSEUDO_VISIBILITY macro isn't defined until after including
os_defines.h, so we can't use _GLIBCXX_VISIBILITY early in c++config.
Replace the uses of that macro with #pragma visibility push(default)
instead.

libstdc++-v3/ChangeLog:

PR libstdc++/104807
* include/bits/c++config (__terminate, __glibcxx_assert_fail):
Replace _GLIBCXX_VISIBILITY on function with visibility pragma.
(__is_constant_evaluated): Add visibility pragma.

[Bug c/104822] New: -Wscalar-storage-order warning for initialization from NULL seems useless

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

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

Bug ID: 104822
   Summary: -Wscalar-storage-order warning for initialization from
NULL seems useless
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct S {
  int i;
} __attribute__((scalar_storage_order("big-endian")));

struct S *p = NULL;


This warns on x86:



sso.c:7:15: warning: initialization of ‘struct S *’ from pointer type ‘void *’
with incompatible scalar storage order [-Wscalar-storage-order]
7 | struct S *p = NULL;
  |   ^~~~


This doesn't seem useful. A null pointer cannot be derferenced, so there is no
chance of undefined behaviour caused by type punning struct T { int i; } as
struct S or vice versa.

Could the warning be suppressed static init of a pointer using NULL?

[Bug analyzer/104821] RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks

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

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

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)
Copy&paste error:
  result->m_b = malloc (sz_c);
should have been:
  result->m_c = malloc (sz_c);

[Bug analyzer/104821] RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks

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

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

--- Comment #1 from David Malcolm  ---
Example: https://godbolt.org/z/afvEd99qn


#include 

struct s
{
  void *m_a;
  void *m_b;
  void *m_c;
};

struct s *
make_s (size_t sz_a, size_t sz_b, size_t sz_c)
{
  struct s *result = calloc (1, sizeof (struct s));
  if (!result)
return NULL;
  result->m_a = malloc (sz_a);
  if (!result->m_a)
goto err;
  result->m_b = malloc (sz_b);
  if (!result->m_b)
goto err;
  result->m_b = malloc (sz_c);
  if (!result->m_c)
goto err;
  return result;

 err:
  free (result->m_c);
  free (result->m_b);
  free (result->m_a);
  free (result);
  return NULL;
}

void test ()
{
  struct s *ptr = make_s (5, 10, 15);
  /* now leak ptr.  */
}



This emits 4 -Wanalyzer-malloc-leak warnings with almost identical paths,
mostly just varying in the "allocated here" messages.

[Bug c++/104803] if consteval error from branch that isn't evaluated anyway

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Barry Revzin  ---
Ugh, sorry. You guys are right. gcc is correct to reject the example. Bad bug
report.

[Bug analyzer/104821] New: RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks

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

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

Bug ID: 104821
   Summary: RFE: consolidate analyzer leak diagnostics by
considering indirect vs direct leaks
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

PR analyzer/101983 reports a pair of -Wanalyzer-malloc-leak warnings at the
same program point, where both:
  *res
and
  *(res->a)
are leaked.

This is a common case where we have a direct leak (of '*res'), leading to
indirect leaks of the things *res is pointing to (of '*(res->a)').

Currently we emit all of these leak warnings, and don't distinguish between
them.

Idea: report the direct leaks, and consolidate all of indirect leaks as notes
on the direct leaks:

e.g. 
  warning: leak of 'ptr'
  [...execution path here...]
  note: direct leak of 'ptr' leads to indirect leak of 'ptr->foo'
  [...execution path here?  or just show the allocation point of 'ptr->foo']
  note: indirect leak of 'ptr->foo' leads to indirect leak of 'ptr->foo->bar'
  [...etc...]

where we can envisage a tree structure of leaks that are reponsible for other
leaks.  We could even visualize this tree with ASCII art, showing the subgraph
of objects and where it becomes unreachable.

Doing so could reduce the verbosity of the analyzer, making the report to the
end-user a little "higher-level".

[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute since r12-4608-gb4702276615ff8d4

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed.

[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute since r12-4608-gb4702276615ff8d4

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

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

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

https://gcc.gnu.org/g:111754595cf8d3a8ae7063a42ac4cea18a304711

commit r12-7521-g111754595cf8d3a8ae7063a42ac4cea18a304711
Author: Martin Liska 
Date:   Fri Feb 4 15:50:17 2022 +0100

opts: fix -gtoggle + optimize attribute

Note -fvar-tracking is enabled automatically with OPT_LEVELS_1_PLUS and
so we need to drop it if we are called from optimize attribute and the
option is unset.

PR middle-end/104381

gcc/ChangeLog:

* opts.cc (finish_options): If debug info is disabled
(debug_info_level) and -fvar-tracking is unset, disable it.

gcc/testsuite/ChangeLog:

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

[Bug rtl-optimization/104814] [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
What options is this with?  Which isa/tuning?

[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps

[andrew.cooper3 at citrix dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Cooper  ---
(In reply to H.J. Lu from comment #5)
> Are you suggesting to add an option to generate jump table with ENDBR?

Jump tables are a legitimate optimisation.  NOTRACK is a weakness in CET
protections, and fully hardened userspace (as well as kernels) will want to run
with MSR_{U,S}_CET.NOTRACK_EN=0.

There should be some future where jump tables can be used in combination with
NOTRACK_EN=0.

[Bug target/104815] [nvptx] Use bitbucket operand when REG_UNUSED

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

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

--- Comment #1 from Tom de Vries  ---
With the tentative patch, I'm running into:
...
ptxas 2224-1.o, line 72; error   : Result discard mode is not allowed for
instruction 'ld'
nvptx-as: ptxas terminated with signal 11 [Segmentation fault], core dumped
...

For:
...
{
.param.u32 %value_in;   
.param.u64 %out_arg1;   
st.param.u64 [%out_arg1], %r61; 
call (%value_in), call_critical_lisp_code, (%out_arg1); 
ld.param.u32_, [%value_in]; 
}
...

Now trying a more restrictive approach, using an operand modifier x, only used
on atom operations, like so:
...
-  = "%.\\tatom%A1.add%t0\\t%0, %1, %2;";
+  = "%.\\tatom%A1.add%t0\\t%x0, %1, %2;";
...

[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps

[peterz at infradead dot org via Gcc-bugs]

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

--- Comment #6 from peterz at infradead dot org ---
(In reply to H.J. Lu from comment #5)
> (In reply to Andrew Cooper from comment #4)
> > I've worked around this in Xen with:
> > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;
> > h=9d4a44380d273de22d5753883cbf5581795ff24d and 
> > https://lore.kernel.org/lkml/YiXpv0q88paPHPqF@hirez.programming.kicks-ass.
> > net/ is pending for Linux.
> > 
> > IMO, it's an error that -fcf-protection=branch is not obeyed for jump
> > tables, and we don't want to end up in a situation where jump tables are
> > unusable with CET.
> 
> Are you suggesting to add an option to generate jump table with ENDBR?

I would suggest having -fcf-protection=branch generate ENDBR for jump-tables
and never generate NOTRACK prefix. Then add a mode that allows NOTRACK
prefixes, perhaps -fcf-protection=branch,notrack.

IBT without NOTRACK is the strongest form; it would be daft to require
additional parameters for that.

[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Andrew Cooper from comment #4)
> I've worked around this in Xen with:
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;
> h=9d4a44380d273de22d5753883cbf5581795ff24d and 
> https://lore.kernel.org/lkml/YiXpv0q88paPHPqF@hirez.programming.kicks-ass.
> net/ is pending for Linux.
> 
> IMO, it's an error that -fcf-protection=branch is not obeyed for jump
> tables, and we don't want to end up in a situation where jump tables are
> unusable with CET.

Are you suggesting to add an option to generate jump table with ENDBR?

[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps

[andrew.cooper3 at citrix dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Cooper  ---
I've worked around this in Xen with:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9d4a44380d273de22d5753883cbf5581795ff24d
and 
https://lore.kernel.org/lkml/yixpv0q88paph...@hirez.programming.kicks-ass.net/
is pending for Linux.

IMO, it's an error that -fcf-protection=branch is not obeyed for jump tables,
and we don't want to end up in a situation where jump tables are unusable with
CET.

[Bug target/104820] New: mips: ICE in int_mode_for_mode, at stor-layout.cc:407 with -fzero-call-used-regs=all -mips4

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Bug ID: 104820
   Summary: mips: ICE in int_mode_for_mode, at stor-layout.cc:407
with -fzero-call-used-regs=all -mips4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at mengyan1223 dot wang
  Target Milestone: ---

May be related to PR104817, but the stack backtrace is different:

echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -nostdinc
-fzero-call-used-regs=all  -mips4
 t
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 1208k}  {heap 1208k} 
{heap 1208k}  {heap 1208k}  {heap 1208k}
 {heap 1208k}  {heap 1208k}  {heap
1208k}Streaming LTO
  {heap 1208k}  {heap 1208k}  {heap 1208k}
 {heap 1208k}  {heap 1208k}  {heap
1208k}Assembling functions:
 tduring RTL pass: zero_call_used_regs

: In function ‘t’:
:1:10: internal compiler error: in int_mode_for_mode, at
stor-layout.cc:407
0x13498b9 int_mode_for_mode(machine_mode)
../../gcc/gcc/stor-layout.cc:407
0xdf06ea emit_move_via_integer
../../gcc/gcc/expr.cc:3615
0xdf10ea emit_move_ccmode
../../gcc/gcc/expr.cc:3834
0xdf17ff emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:3974
0xdf21ab emit_move_insn(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:4125
0x135d39b default_zero_call_used_regs(HARD_REG_SET)
../../gcc/gcc/targhooks.cc:1040
0xe98230 gen_call_used_regs_seq
../../gcc/gcc/function.cc:5927
0xe99800 execute
../../gcc/gcc/function.cc:6697
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-03-07

--- Comment #3 from H.J. Lu  ---
(In reply to Richard Biener from comment #2)
> Documentation should probably also amended to reflect this limitation (or
> -fcf-protection=branch should implicitely disable jump-tables).

We should document this limitation and update -fno-jump-tables documentation:

'-fno-jump-tables'
 Do not use jump tables for switch statements even where it would be
 more efficient than other code generation strategies.  This option
 is of use in conjunction with '-fpic' or '-fPIC' for building code
 that forms part of a dynamic linker and cannot reference the
 address of a jump table.  On some targets, jump tables do not
 require a GOT and this option is not needed.

[Bug ipa/104813] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in adjust_references_in_caller, at ipa-cp.cc:4963 since r12-2523-g13586172d0b70c9d

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
Mine.

[Bug fortran/104696] [OpenMP] Implicit mapping breaks struct mapping

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

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #1)
> Namely:
>  test.c--
> struct s { int *d; };

It makes more sense to use 'int d;' to match Fortran. Doing so yields in the
gimple dump:

#pragma omp target num_teams(1) thread_limit(0)
  map(struct:x [len: 1]) map(tofrom:x.q.d [len: 4])
#pragma omp target num_teams(1) thread_limit(0)
  map(tofrom:x [len: 4194328][implicit]) map(tofrom:x.r[1].d [len: 4])

Thus, C and Fortran show the same issue.

[Bug target/104816] -fcf-protection=branch should generate endbr instead of notrack jumps

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |12.0
   Severity|normal  |enhancement

--- Comment #2 from Richard Biener  ---
Documentation should probably also amended to reflect this limitation (or
-fcf-protection=branch should implicitely disable jump-tables).

[Bug tree-optimization/104789] [12 Regression] New -Wstringop-overflow false positive since r12-5863-g9354a7d70caef1c9

[rverschelde at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Rémi Verschelde  ---
Took me a while, but I was able to make a proper reduced testcase by cutting
down the Godot case to the very minimal.

It's a bit convoluted (and the code doesn't make any sense anymore), but the
complexity seems to trigger the false positive I intended to report originally.

```
$ cat godot-stringop.cpp
#include 
#include 

uint32_t components = 3;

void commit_temp_packets() {
// Should be sufficient?
if (components > 3) { return; }

uint8_t header[8];
uint32_t header_bytes = 0;
for (uint32_t i = 0; i < components; i++) {
header_bytes += 2;
}

uint32_t max_shifts[3] = { 0, 0, 0 };

for (uint32_t i = 1; i < 2; i++) {
for (uint32_t j = 0; j < components; j++) {
max_shifts[j] = 1;
}
}
header_bytes += 2;

// Should definitely be sufficient.
if (header_bytes > 7) { return; }

while (header_bytes % 4 != 0) {
header[header_bytes++] = 0;
}

std::vector data;

for (uint32_t i = 0; i < header_bytes; i++) {
data.push_back(header[i]);
}

uint32_t bit_buffer = 0;
uint32_t bits_used = 0;

for (uint32_t i = 1; i < 2; i++) {
for (uint32_t j = 0; j < components; j++) {
bit_buffer |= 1 << bits_used;
bits_used += max_shifts[j] + 1;
while (bits_used >= 8) {
uint8_t byte = bit_buffer & 0xFF;
data.push_back(byte);
bit_buffer >>= 8;
bits_used -= 8;
}
}
}
}

$ g++ godot-stringop.cpp -c -Werror=all -O3
godot-stringop.cpp: In function ‘void commit_temp_packets()’:
godot-stringop.cpp:29:40: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   29 | header[header_bytes++] = 0;
  | ~~~^~~
godot-stringop.cpp:10:17: note: at offset 8 into destination object ‘header’ of
size 8
   10 | uint8_t header[8];
  | ^~
godot-stringop.cpp:29:40: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   29 | header[header_bytes++] = 0;
  | ~~~^~~
godot-stringop.cpp:10:17: note: at offset [9, 11] into destination object
‘header’ of size 8
   10 | uint8_t header[8];
  | ^~
cc1plus: some warnings being treated as errors
```

Interestingly, there are no changes to `header_bytes` or `components` after
line 29, yet the code that follows seems needed to trigger the warning.