[Bug target/102326] ICE in tree_to_uhwi, at tree.c:4520

[pc.wang at linux dot alibaba.com via Gcc-bugs]

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

Pengcheng Wang  changed:

   What|Removed |Added

  Attachment #51473|0   |1
is obsolete||

--- Comment #2 from Pengcheng Wang  ---
Created attachment 51476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51476=edit
V2 patch after reviewing

[Bug testsuite/102394] Gfortran testsuite could avoid target specific tests

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Rimvydas (RJ)  ---
Also with updated toolchain to glibc-2.34 (still not sure if this was not
happening before) noticed that very rarely one test in particular sometimes
fail during parallel check-gcc-fortran. Running explicitly is more
reproducible, STOP 1, irnk == -1000:
make -j20  check-gcc-fortran RUNTESTFLAGS=dg.exp=PR93963.f90

FAIL: gfortran.dg/PR93963.f90   -O1  execution test
=== gfortran Summary ===
# of expected passes11
# of unexpected failures1

[Bug testsuite/102394] Gfortran testsuite could avoid target specific tests

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Rimvydas (RJ)  ---
Created attachment 51475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51475=edit
possible generalizations

=== gfortran Summary ===

-# of expected passes   60534
+# of expected passes   60602
 # of expected failures 507
 # of unresolved testcases  30
-# of unsupported tests 82
+# of unsupported tests 1
 /build/trunk/gcc/gfortran  version 12.0.0 20210918 (experimental) [master
r12-3643-g18b57c1d4a8] (GCC)

UNSUPPORTED: gfortran.dg/prof/dynamic_dispatch_6.f03 -fauto-profile
that requires perf(1) and autofdo.

[Bug testsuite/102394] New: Gfortran testsuite could avoid target specific tests

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 102394
   Summary: Gfortran testsuite could avoid target specific tests
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Given latest gcc/testsuite/gfortran.dg/c-interop/ failures it might be a good
time generalize most of gcc/testsuite/gfortran.dg/ tests for easier detection
of skipped tests. This could avoid a need to add gcc/testsuite/gfortran.target/
in the future.  Currently there are over 80 UNSUPPORTED tests on
x86_64-unknown-linux-gnu.  Most of them are trivial to make generic, including
winapi.f90.

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

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

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:7afcb534239014a713e1f234c8734644245e5c38

commit r12-3644-g7afcb534239014a713e1f234c8734644245e5c38
Author: liuhongt 
Date:   Sat Sep 18 12:14:32 2021 +0800

Support embedded broadcast for AVX512FP16 instructions.

gcc/ChangeLog:

PR target/87767
* config/i386/i386.c (ix86_print_operand): Handle
V8HF/V16HF/V32HFmode.
* config/i386/i386.h (VALID_BCST_MODE_P): Add HFmode.
* config/i386/sse.md (avx512bcst): Remove.

gcc/testsuite/ChangeLog:

* gcc.target/i386/avx512fp16-broadcast-1.c: New test.
* gcc.target/i386/avx512fp16-broadcast-2.c: New test.

[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |6.0

--- Comment #26 from Andrew Pinski  ---
Fixed for GCC 6 by r6-4443.

https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Common-Function-Attributes.html#index-target_005fclones-function-attribute

[Bug tree-optimization/102393] Failure to optimize 2 8-bit stores into a single 16-bit store

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

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

--- Comment #2 from Andrew Pinski  ---
that is offset = 0; works.

[Bug tree-optimization/102393] Failure to optimize 2 8-bit stores into a single 16-bit store

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102391
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Really the same issue as PR 102391 bug on the store side rather than the load
side.

[Bug tree-optimization/102392] Failure to optimize a sign extension to a zero extension

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-18
 Status|UNCONFIRMED |NEW
  Component|target  |tree-optimization
   Keywords|ABI |

--- Comment #3 from Andrew Pinski  ---
A better testcase is:
void g(int32_t *x, int64_t *y)
{
if (*x < 0)
__builtin_unreachable();
*y = (*x);
}

To see what LLVM is really doing.
GCC:
movslq  (%rdi), %rax
movq%rax, (%rsi)
ret

VS LLVM:
movl(%rdi), %eax
movq%rax, (%rsi)
retq

There might be a dup of this bug somewhere too.

[Bug tree-optimization/102391] Failure to optimize adjacent 8-bit loads into a single bigger load

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-18
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
GCC can figure out case offset = 0;

There might be a dup of this one too.

[Bug tree-optimization/102393] New: Failure to optimize 2 8-bit stores into a single 16-bit store

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102393
   Summary: Failure to optimize 2 8-bit stores into a single
16-bit store
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

#include 

void HeaderWriteU16LE(int offset, uint16_t value, uint8_t *RomHeader)
{
RomHeader[offset] = value;
RomHeader[offset + 1] = value >> 8;
}

Non-withstanding aliasing, this can be optimized to `*(uint16_t *)(RomHeader +
offset) = value`. This transformation is done by LLVM, but not by GCC.

Sample AMD64 output for this from GCC:

HeaderWriteU16LE:
  movsx rdi, edi
  mov eax, esi
  mov BYTE PTR [rdx+rdi], sil
  mov BYTE PTR [rdx+1+rdi], ah
  ret

And from LLVM:

HeaderWriteU16LE:
  movsxd rax, edi
  mov word ptr [rdx + rax], si
  ret

PS: The equivalent pattern for 4 8-bit stores gets optimized into a single
32-bit store.

[Bug tree-optimization/102391] Failure to optimize adjacent 8-bit loads into a single bigger load

[gabravier at gmail dot com via Gcc-bugs]

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

Gabriel Ravier  changed:

   What|Removed |Added

Summary|Failure to optimize 2 8-bit |Failure to optimize
   |loads into a single 16-bit  |adjacent 8-bit loads into a
   |load|single bigger load

--- Comment #1 from Gabriel Ravier  ---
Note: this also equivalently works on bigger sizes:

uint32_t HeaderReadU32LE(int offset, uint8_t *RomHeader)
{
return RomHeader[offset] |
(RomHeader[offset + 1] << 8) |
(RomHeader[offset + 2] << 16) |
(RomHeader[offset + 3] << 24);
}

On AMD64, GCC outputs this:

HeaderReadU32LE:
  movsx rdi, edi
  movzx eax, BYTE PTR [rsi+1+rdi]
  movzx edx, BYTE PTR [rsi+2+rdi]
  sal eax, 8
  sal edx, 16
  or eax, edx
  movzx edx, BYTE PTR [rsi+rdi]
  or eax, edx
  movzx edx, BYTE PTR [rsi+3+rdi]
  sal edx, 24
  or eax, edx
  ret

LLVM manages this:

HeaderReadU32LE:
  movsxd rax, edi
  mov eax, dword ptr [rsi + rax]
  ret

[Bug target/102392] Failure to optimize a sign extension to a zero extension

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Failure to optimize out |Failure to optimize a sign
   |sign extension when input   |extension to a zero
   |is non-negative |extension
  Component|middle-end  |target

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Actually this can be done without the __builtin_unreachable due to the abi.

I mean this can never be done without it. Also a zero extend vs sign extend
might be the same cost really. So it does not matter in the end.

Note the move you reference is  zero extend.

[Bug middle-end/102392] Failure to optimize out sign extension when input is non-negative

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI
 Target||X86_64-linux-gnu
  Component|tree-optimization   |middle-end

--- Comment #1 from Andrew Pinski  ---
Actually this can be done without the __builtin_unreachable due to the abi.

[Bug tree-optimization/102392] New: Failure to optimize out sign extension when input is non-negative

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102392
   Summary: Failure to optimize out sign extension when input is
non-negative
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

#include 

void f(int64_t x);

void g(int32_t x)
{
if (x < 0)
__builtin_unreachable();
f(x);
}

This can be optimized to avoid the sign extension since x can't be under 0.
This optimization is done by LLVM, but not by GCC.

Sample resulting assembly from GCC:

g:
  movsx rdi, edi
  jmp f

from LLVM:

g:
  mov edi, edi
  jmp f

(PS: I originally found this while looking at the code that led me to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102391: an error check earlier in
the code (not in the example cited there) wound up making this assumption
possible, and slightly changed the assembly code emitted by LLVM there to be
even more efficient)

[Bug tree-optimization/102391] New: Failure to optimize 2 8-bit loads into a single 16-bit load

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102391
   Summary: Failure to optimize 2 8-bit loads into a single 16-bit
load
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

#include 

uint16_t HeaderReadU16LE(int offset, uint8_t *RomHeader)
{
return RomHeader[offset] |
(RomHeader[offset + 1] << 8);
}

This can be optimized into a single 16-bit load. On -O3, this optimization is
done by LLVM, but not by GCC.

This winds up affecting the resulting assembly quite a bit:

AMD64 GCC:

HeaderReadU16LE:
  movsx rdi, edi
  movzx edx, BYTE PTR [rsi+1+rdi]
  movzx eax, BYTE PTR [rsi+rdi]
  sal edx, 8
  or eax, edx
  ret

AMD64 LLVM:

HeaderReadU16LE:
  movsxd rax, edi
  movzx eax, word ptr [rsi + rax]
  ret

[Bug libfortran/102370] Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC

[longb at cray dot com via Gcc-bugs]

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

--- Comment #2 from Bill Long  ---
I've sent a question back to the original submitter.  On completion, the first
argument to MOVE_ALLOC is unallocated, so it does look suspicious to be
printing a component of an unallocated structure.  I'll update when I get a
revised test case.

[Bug bootstrap/102389] [12 Regression] --with-build-config=bootstrap-lto bootstrap is broken due to r12-3491

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

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

--- Comment #3 from Andrew Pinski  ---
Oh according to https://sourceware.org/bugzilla/show_bug.cgi?id=25355, we need
to require binutils 2.35 or newer to do this now.

[Bug bootstrap/102389] [12 Regression] --with-build-config=bootstrap-lto bootstrap is broken due to r12-3491

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

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

--- Comment #2 from Andrew Pinski  ---
Still fails:
conftest.c:6:12: error: variable 'nm_test_var' redeclared as function
6 | extern int nm_test_var();
  |^
conftest.c:4:6: note: previously declared here
4 |
  |  ^
lto1: fatal error: errors during merging of translation units
compilation terminated.

[Bug libfortran/102370] Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-09-17
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Are you sure the code is valid?

Even Intel crashes when it reaches the print.
Adding

  print *, allocated (temp)

before

  print *, temp%val

print for both:

 F

So the final print looks invalid.

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Committed as per Jakub's LGTM and announced here:

https://gcc.gnu.org/pipermail/fortran/2021-September/056540.html

[Bug fortran/102390] New: IMPLICIT SAVE not properly implemented

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

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

Bug ID: 102390
   Summary: IMPLICIT SAVE not properly implemented
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

While working on pr102366, it became clear that we do not properly handle some
situations where the Fortran standard requires variables to be IMPLICIT SAVE.

F2018  8.5.16 SAVE attribute

(4) A variable, common block, or procedure pointer declared in the scoping unit
of a main program, module, or submodule implicitly has the SAVE attribute,
which
may be confirmed by explicit specification. If a common block has the SAVE
attribute in any other kind of scoping unit, it shall have the SAVE attribute
in every scoping unit that is not of a main program, module, or submodule.

There is code in decl.c:match_attr_spec that attempts to handle this for
modules and submodules.

However, the program

  real(kind=4) :: a(10)
  a=1.0
end

fails to place array a in static memory (for default values of option
-fmax-stack-var-size).  As long as there is no program statement, we do
not have the proper context to set IMPLICIT_SAVE.

But even with a program statement the current gfortran will place a in static
memory unless one sets e.g. -fmax-stack-var-size=1 .

For standard conforming code and -std=f2018 (or earlier) this needs fixing.

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:51166eb2c534692c3c7779def24f83c8c3811b98

commit r12-3639-g51166eb2c534692c3c7779def24f83c8c3811b98
Author: Harald Anlauf 
Date:   Fri Sep 17 21:45:33 2021 +0200

Fortran - (large) arrays in the main shall be static

gcc/fortran/ChangeLog:

PR fortran/102366
* trans-decl.c (gfc_finish_var_decl): Disable the warning message
for variables moved from stack to static storange if they are
declared in the main, but allow the move to happen.

gcc/testsuite/ChangeLog:

PR fortran/102366
* gfortran.dg/pr102366.f90: New test.

[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier

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

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

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

https://gcc.gnu.org/g:1fa2c5a695bb962ffcf8abed49f69cdcc59d0e61

commit r12-3637-g1fa2c5a695bb962ffcf8abed49f69cdcc59d0e61
Author: Jonathan Wakely 
Date:   Fri Sep 17 12:27:02 2021 +0100

libstdc++: Fix last std::tuple constructor missing 'constexpr' [PR102270]

Also rename the test so it actually runs.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/102270
* include/std/tuple (_Tuple_impl): Add constexpr to constructor
missed in previous patch.
* testsuite/20_util/tuple/cons/102270.C: Moved to...
* testsuite/20_util/tuple/cons/102270.cc: ...here.
* testsuite/util/testsuite_allocator.h (SimpleAllocator): Add
constexpr to constructor so it can be used for C++20 tests.

[Bug bootstrap/102389] [12 Regression] --with-build-config=bootstrap-lto bootstrap is broken due to r12-3491

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
Mine.  I have to see if using gcc-nm and exporting NM will fix this issue; it
might ...

[Bug bootstrap/102389] [12 Regression] --with-build-config=bootstrap-lto bootstrap is broken due to r12-3491

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug bootstrap/102389] New: [12 Regression] --with-build-config=bootstrap-lto bootstrap is broken due to r12-3491

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

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

Bug ID: 102389
   Summary: [12 Regression] --with-build-config=bootstrap-lto
bootstrap is broken due to r12-3491
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build, lto
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

checking locale.h presence... libtool: link: nm  .libs/lto-plugin.o   |  |
/bin/sed 's/.* //' | sort | uniq > .libs/liblto_plugin.exp
./libtool: eval: line 1118: syntax error near unexpected token `|'
./libtool: eval: line 1118: `nm  .libs/lto-plugin.o   |  | /bin/sed 's/.* //' |
sort | uniq > .libs/liblto_plugin.exp'
Makefile:466: recipe for target 'liblto_plugin.la' failed
make[4]: *** [liblto_plugin.la] Error 2



- CUT 

After r12-3491-g9e58de3ce00, nm is used but libtool's configure breaks (it
looks like it was always broken, just we did not use that feature of libtool
until now):
configure:7427: checking command to parse nm output from 
/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/xgcc
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/lib/ -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/include -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/sys-include   -fno-checking
object
configure:7545: 
/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/xgcc
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/lib/ -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/include -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/sys-include   -fno-checking
-c -g -O2 -fno-checking -flto=jobserver -frandom-seed=1  conftest.c >&5
configure:7548: $? = 0
configure:7552: nm conftest.o \| sed -n -e 's/^.*[
]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' \>
conftest.nm
configure:7555: $? = 0
configure:7609: 
/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/xgcc
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/lib/ -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/include -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/sys-include   -fno-checking
-o conftest -g -O2 -fno-checking -flto=jobserver -frandom-seed=1 
-static-libstdc++ -static-libgcc  conftest.c conftstm.o >&5
conftest.c:6:12: error: variable 'nm_test_var' redeclared as function
6 | extern int nm_test_var();
  |^
conftest.c:4:6: note: previously declared here
4 |
  |  ^
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: fatal error:
/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/xgcc returned 1
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
configure:7612: $? = 1
configure:7545: 
/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/xgcc
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./prev-gcc/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/lib/ -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/include -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/sys-include   -fno-checking
-c -g -O2 -fno-checking -flto=jobserver -frandom-seed=1  conftest.c >&5
configure:7548: $? = 0
configure:7552: nm conftest.o \| sed -n -e 's/^.*[
]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p'
\> conftest.nm
configure:7555: $? = 0
cannot run sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][
 ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p'
configure:7647: result: failed

 CUT 
configure:7427: checking command to parse nm output from gcc object
configure:7545: gcc -c -g  conftest.c >&5
configure:7548: $? = 0
configure:7552: nm conftest.o \| sed -n -e 's/^.*[
]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' \>
conftest.nm
configure:7555: $? = 0
configure:7609: gcc -o conftest -g  -static-libstdc++ -static-libgcc 
conftest.c conftstm.o >&5
configure:7612: $? = 0
configure:7650: result: ok

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
In decl.c:match_attr_spec we have:

5818  /* Since Fortran 2008 module variables implicitly have the SAVE
attribute.  */
5819  if ((gfc_current_state () == COMP_MODULE
5820   || gfc_current_state () == COMP_SUBMODULE)
5821  && !current_attr.save
5822  && (gfc_option.allow_std & GFC_STD_F2008) != 0)
5823current_attr.save = SAVE_IMPLICIT;

I tried to extend that to the case of COMP_PROGRAM, but:

(gdb) p gfc_state_stack->state 
$162 = COMP_NONE

But when I add

program test

at the beginning of the file, I find

(gdb) p gfc_state_stack->state 
$164 = COMP_PROGRAM

So this may be too early to handle arrays in the main.

Given Jakub's comment, I'll fix that and regtest.

[Bug ipa/102388] [12 Regression] ICE in duplicate, at ipa-prop.c:4436 since r12-2523-g13586172d0b70c9d

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Last reconfirmed||2021-09-17
  Known to work||11.2.0
  Known to fail||12.0
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW

[Bug ipa/102388] New: [12 Regression] ICE in duplicate, at ipa-prop.c:4436 since r12-2523-g13586172d0b70c9d

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

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

Bug ID: 102388
   Summary: [12 Regression] ICE in duplicate, at ipa-prop.c:4436
since r12-2523-g13586172d0b70c9d
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51474=edit
test-case

It's reduced from 523.xalancbmk_r.

$ g++ ice2/*.ii -O2 -flto -fno-ipa-modref
...
during IPA pass: inline
lto1: internal compiler error: in duplicate, at ipa-prop.c:4436
0x6c5062 ipa_edge_args_sum_t::duplicate(cgraph_edge*, cgraph_edge*,
ipa_edge_args*, ipa_edge_args*)
/home/marxin/Programming/gcc/gcc/ipa-prop.c:4436
0x91c69b symbol_table::call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
/home/marxin/Programming/gcc/gcc/cgraph.c:454
0x9214f6 cgraph_edge::make_speculative(cgraph_node*, profile_count, unsigned
int)
/home/marxin/Programming/gcc/gcc/cgraph.c:1127
0xba03ae try_make_edge_direct_simple_call
/home/marxin/Programming/gcc/gcc/ipa-prop.c:3780
0xba03ae update_indirect_edges_after_inlining
/home/marxin/Programming/gcc/gcc/ipa-prop.c:4000
0xba03ae propagate_info_to_inlined_callees
/home/marxin/Programming/gcc/gcc/ipa-prop.c:4092
0xb9fcf0 propagate_info_to_inlined_callees
/home/marxin/Programming/gcc/gcc/ipa-prop.c:4096
0xba0bbb ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
/home/marxin/Programming/gcc/gcc/ipa-prop.c:4272
0xb6c98d inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:508
0x1aa8ff9 inline_to_all_callers_1
/home/marxin/Programming/gcc/gcc/ipa-inline.c:2462
0x1aa8ff9 inline_to_all_callers
/home/marxin/Programming/gcc/gcc/ipa-inline.c:2487
0x1aaa6ba cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
/home/marxin/Programming/gcc/gcc/cgraph.h:3403
0x1aaa6ba ipa_inline
/home/marxin/Programming/gcc/gcc/ipa-inline.c:2812
0x1aaa6ba execute
/home/marxin/Programming/gcc/gcc/ipa-inline.c:3142
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

--- Comment #12 from Jakub Jelinek  ---
That LGTM, except formatting - && shouldn't be at the end of line per coding
conventions, but on the start of next line.

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #10)

> The problem is gone if I revert r12-3129.

But then it regresses on pr98411.  See for yourself compiling with -Wall.

Something like

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index bed61e2325d..b022d818e82 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -743,7 +743,6 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)

   /* Keep variables larger than max-stack-var-size off stack.  */
   if (!(sym->ns->proc_name && sym->ns->proc_name->attr.recursive)
-  && !(sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program)
   && !sym->attr.automatic
   && sym->attr.save != SAVE_EXPLICIT
   && sym->attr.save != SAVE_IMPLICIT
@@ -757,7 +756,9 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
  || sym->attr.allocatable)
   && !DECL_ARTIFICIAL (decl))
 {
-  if (flag_max_stack_var_size > 0)
+  if (flag_max_stack_var_size > 0
+ && !(sym->ns->proc_name &&
+  sym->ns->proc_name->attr.is_main_program))
gfc_warning (OPT_Wsurprising,
 "Array %qs at %L is larger than limit set by "
 "%<-fmax-stack-var-size=%>, moved from stack to static "

disables the warning for arrays in the main.

[Bug bootstrap/100730] h8300-linux: unused parameter, statement may fall through, control reaches end of non-void function

[jbglaw--- via Gcc-bugs]

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

--- Comment #2 from Jan-Benedict Glaw  ---
Confirmed that I see this as fixed in the logs. (And I need to put that build
host to the datacenter in Münster and announce it publically...)

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

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

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

Bug 102200 Summary: [12 Regression] ICE on a min of a decl and pointer in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102200

   What|Removed |Added

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

[Bug middle-end/102200] [12 Regression] ICE on a min of a decl and pointer in a loop

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Summary|[12 Regression] ice in  |[12 Regression] ICE on a
   |put_ref, at |min of a decl and pointer
   |pointer-query.cc:1351 since |in a loop
   |r12-3300-gece28da924ddda8b  |

--- Comment #6 from Martin Sebor  ---
Fixed.

[Bug middle-end/102200] [12 Regression] ice in put_ref, at pointer-query.cc:1351 since r12-3300-gece28da924ddda8b

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:31e924c52f430d81f030a2fa9f60b73a5a0d2126

commit r12-3629-g31e924c52f430d81f030a2fa9f60b73a5a0d2126
Author: Martin Sebor 
Date:   Fri Sep 17 10:36:54 2021 -0600

Better handle MIN/MAX_EXPR of unrelated objects [PR102200].

Resolves:
PR middle-end/102200 - ICE on a min of a decl and pointer in a loop

gcc/ChangeLog:

PR middle-end/102200
* pointer-query.cc (access_ref::inform_access): Handle
MIN/MAX_EXPR.
(handle_min_max_size): Change argument.  Store original SSA_NAME
for
operands to potentially distinct (sub)objects.
(compute_objsize_r): Adjust call to the above.

gcc/testsuite/ChangeLog:

PR middle-end/102200
* gcc.dg/Wstringop-overflow-62.c: Adjust text of an expected note.
* gcc.dg/Warray-bounds-89.c: New test.
* gcc.dg/Wstringop-overflow-74.c: New test.
* gcc.dg/Wstringop-overflow-75.c: New test.
* gcc.dg/Wstringop-overflow-76.c: New test.

[Bug c/102245] [12 Regression] false int-in-bool-context warning with shift

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:2578a3870ef849dc77e98796600181b64ae4fd61

commit r12-3623-g2578a3870ef849dc77e98796600181b64ae4fd61
Author: Roger Sayle 
Date:   Fri Sep 17 15:57:34 2021 +0100

PR c/102245: Disable sign-changing optimization for shifts by zero.

Respecting Jakub's suggestion that it may be better to warn-on-valid for
"if (x << 0)" as the author might have intended "if (x < 0)" [which will
also warn when x is _Bool], the simplest way to resolve this regression
is to disable the recently added fold transformation for shifts by zero;
these will be optimized later (elsewhere).  Guarding against integer_zerop
is the simplest of three alternatives; the second being to only apply
this transformation to GIMPLE and not GENERIC, and the third (potentially)
being to explicitly handle shifts by zero here, with an (if cond then
else),
optimizing the expression to a convert, but awkwardly duplicating a
more general transformation earlier in match.pd's shift simplifications.

2021-09-17  Roger Sayle  

gcc/ChangeLog
PR c/102245
* match.pd (shift optimizations): Disable recent sign-changing
optimization for shifts by zero, these will be folded later.

gcc/testsuite/ChangeLog
PR c/102245
* gcc.dg/Wint-in-bool-context-4.c: New test case.

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||akhilesh.k at samsung dot com

--- Comment #7 from Christophe Lyon  ---
*** Bug 90721 has been marked as a duplicate of this bug. ***

[Bug target/90721] [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Christophe Lyon  ---
I think this is a dup of PR69538

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

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

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

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

--- Comment #6 from Martin Liška  ---
Quickly looking at the rs6000 code, it fails here:

#1  0x11a0993c in rs6000_invalid_builtin
(fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
../../gcc/config/rs6000/rs6000-call.c:11643
#2  0x11a13134 in rs6000_builtin_decl (code=1603, initialize_p=true) at
../../gcc/config/rs6000/rs6000-call.c:13870
#3  0x115c3900 in unpack_ts_function_decl_value_fields
(bp=0x3fffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
#4  0x115c4790 in streamer_read_tree_bitfields (ib=0x3fffe6a0,
data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
#5  0x10deaa28 in lto_read_tree_1 (ib=0x3fffe6a0,
data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697

which relies on rs6000_builtin_mask. Note the mask is set here:
rs6000_builtin_mask = rs6000_builtin_mask_calculate ();

where rs6000_builtin_mask_calculate is based on TARGET_* values.

I think the mask check should be deferred later as it should be based on proper
target_node that is set via rs6000_set_current_function. It should not check
it in lto_read_tree_1.

[Bug middle-end/102243] [12 Regression] ICE in get_range_query since r12-3300-gece28da924dd

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

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran

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

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

--- Comment #12 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579678.html

[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'

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

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

--- Comment #7 from David Malcolm  ---
Thanks for taking care of this.

[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744

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

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2021-09-17 2:46 a.m., rguenth at gcc dot gnu.org wrote:
> Btw, it works with a cross from x86_64 to hppa64-hp-hpux11, but maybe I'm 
> doing
> it wrong?
It's probably caused by a bug in the TImode support that I'm working on.

[Bug tree-optimization/102387] [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-17
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can take a look.

[Bug tree-optimization/102387] New: [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

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

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

Bug ID: 102387
   Summary: [12 Regression] ICE Segmentation fault since
r12-2429-g62acc72a957b5614
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: richard.sandiford at arm dot com
  Target Milestone: ---

The following crashes:

$ cat loop.f90
   integer, dimension (3, 3) :: a
   call test1(a, (/123456/))
   call test1(a(:2, :), (/124578/))
contains
subroutine test1(p, q)
   integer, dimension(*) :: p
   integer, dimension(:) :: q
   if (any (p(size0) .ne. q)) STOP 
end 
end 

$ gfortran loop.f90 --param=unroll-jam-min-percent=0 -Ofast -fno-tree-ch
--param=max-completely-peeled-insns=1 --param=early-inlining-insns=100
-fno-tree-vrp
loop.f90:8:14:

8 |if (any (p(size0) .ne. q)) STOP
  |  1
Warning: Legacy Extension: REAL array index at (1)
during GIMPLE pass: unrolljam
loop.f90:3:35:

3 |call test1(a(:2, :), (/124578/))
  |   ^
internal compiler error: Segmentation fault
0xf7a54a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0x10ef65c tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-manip.c:1425
0x1bc688b tree_loop_unroll_and_jam
/home/marxin/Programming/gcc/gcc/gimple-loop-jam.c:590
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[hv at crypt dot org via Gcc-bugs]

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

--- Comment #5 from Hugo van der Sanden  ---
(In reply to Martin Sebor from comment #4)
> For functions like pthread_getspecific() and pthread_setspecific() that do
> not access the object GCC provides attribute access none to suppress the
> warning:
> 
>   extern __attribute__ ((access (none, 1))) void f1 (const void *pointer);

Well that's not a solution for developers of perl, since these system headers
are not under our control. I'm not sure it's a solution right now for
developers of those system headers either, since adding the attribute yields a
different warning under slightly earlier versions of gcc, eg with gcc-9.2.1:
test.c:8:1: warning: 'access' attribute directive ignored [-Wattributes]
8 | extern int pthread_setspecific (unsigned int key, const void *pointer)
__attribute__ ((access (none, 2)));
  | ^~

I think we still find the original sort of maybe-uninitialized warnings useful,
so we'll probably just do the useless initialization, and the code will run a
bit slower under gcc.

[Bug middle-end/102386] New: [12 regression] bogus -Wrestrict for unreachable memcpy()

[dimhen at gmail dot com via Gcc-bugs]

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

Bug ID: 102386
   Summary: [12 regression] bogus -Wrestrict for unreachable
memcpy()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r12-3456 PASS
r12-3545 FAIL

$ cat x.i
static int GetHashParam_HP_OPAQUEBLOB_pdwDataLen = 0;
void *memcpy(void *, const void *, unsigned long);
typedef struct {
  int tSimpleBlobHeader;
  int bCurrKey[];
} CRYPT_OPAQUEHASHBLOB;
int GetHashParam_HP_OPAQUEBLOB() {
  CRYPT_OPAQUEHASHBLOB *pBlb;
  if (GetHashParam_HP_OPAQUEBLOB_pdwDataLen) {
void *pcn = pBlb->bCurrKey, *pdwBuff = pBlb->bCurrKey;
int dwDWBufLen = 8;
memcpy(pcn, pdwBuff, sizeof(1) * dwDWBufLen);
  }
  return 1;
}

$ gcc -fpreprocessed -O --param max-early-inliner-iterations=2 -Wrestrict -c
x.i
x.i: In function 'GetHashParam_HP_OPAQUEBLOB':
x.i:12:5: warning: 'memcpy' accessing 32 bytes at offsets 4 and 4 overlaps 32
bytes at offset 4 [-Wrestrict]
   12 | memcpy(pcn, pdwBuff, sizeof(1) * dwDWBufLen);
  | ^~~~


Test extracted from private codebase.
Key part:

static inline void foo(void *p, void *q, int N)
{
   if(p != q)
 memcpy(p, q, N);
}

void bar(void q, void p, int N)
{
   foo(p, q, N);
}

[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE: in |[12 Regression] ICE: in
   |single_pred_edge, at|single_pred_edge, at
   |basic-block.h:350 under |basic-block.h:350 under
   |"-O2 -fno-toplevel-reorder  |"-O2 -fno-toplevel-reorder
   |-fno-tree-ch -fno-tree-dce  |-fno-tree-ch -fno-tree-dce
   |-fno-tree-dominator-opts|-fno-tree-dominator-opts
   |-fno-tree-dse   |-fno-tree-dse
   |-fno-tree-loop-ivcanon  |-fno-tree-loop-ivcanon
   |-fpredictive-commoning" |-fpredictive-commoning"
   ||since
   ||r12-2429-g62acc72a957b5614
  Known to fail||12.0
  Known to work||11.2.0
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r12-2429-g62acc72a957b5614.

[Bug target/102376] [aarch64] using target("sve") attribute without a + is not very helpful on what is wrong

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-17
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
I can handle it. It would be handy recommendation to users.

[Bug target/102375] (aarch64) Should allow space in target attribute

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-09-17
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can handle it.

[Bug target/102374] [x86_64] Should ignore spaces in target attribute

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-17
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
I can handle it.

[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'

[gerald at pfeifer dot com via Gcc-bugs]

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

Gerald Pfeifer  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |gerald at pfeifer dot 
com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Gerald Pfeifer  ---
Passed testing on my regular tester that flagged this issue last night.

[Bug tree-optimization/101145] niter analysis fails for until-wrap condition

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

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

Bug 102364 Summary: [12 Regression] wrong code at -O1 and above on 
x86_64-linux-gnu since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364

   What|Removed |Added

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

[Bug tree-optimization/100740] [9/10/11/12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145

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

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

--- Comment #5 from Martin Liška  ---
*** Bug 102364 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/102364] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-3136-g3673dcf6d6baeb67

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Dup.

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

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

[dominiq at lps dot ens.fr via Gcc-bugs]

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

--- Comment #10 from Dominique d'Humieres  ---
> Seems it changed with r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a

The problem is gone if I revert r12-3129.

[Bug c/78903] __attribute__((section(".ram"))) ignored with -Os or -flto

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
As mentioned section does not block inlining.  So this is exacted.  You need to
use noinline or noipa to get that effect.

[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran

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

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

--- Comment #11 from Tobias Burnus  ---
The problem is an ordering problem.


Namely:

* toplev.c calls:
  lang_hooks.init_options (save_decoded_options_count, save_decoded_options);

which in turn is:

gfc_init_options ( 
{
  ...
  SET_OPTION_IF_UNSET (_options, _options_set,
   cpp_warn_missing_include_dirs, 1);
...
  /* Initialize cpp-related options.  */
  gfc_cpp_init_options (decoded_options_count, decoded_options);
...
}

Thus, cpp_warn_missing_include_dirs is enabled.


Now:
  decode_options (_options, _options_set, ...
is run, which calls:
  read_cmdline_options (opts, opts_set, ...
  → read_cmdline_option
→ handle_option
  → gfc_handle_option
→ gfc_add_include_path
  → gfc_warning_now

and only afterwards decode_options invokes:
  set_option (...)
which then sets:
  global_options_set->x_... = 1
and
  global_options->x_...  = commandline option.
and disables the already shown warning.

[Bug tree-optimization/102382] Missing optimization for strlen after enable O2 vectorization

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 17 Sep 2021, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102382
> 
> --- Comment #4 from Jakub Jelinek  ---
> Not to mention, for calloc like the above where size is non-constant, it
> wouldn't know how many there are (it would need some magic for all).
> Anyway, even constant number of 0s at the end of string > 1 wouldn't really 
> fit
> well into the way how string lengths are invalidated...

Fair enough - the main isse with this PR is the failure to elide the
strlen () though when the store is a vector store.

Btw, DSE would remove the earlier store but obviously we can't
prune parts of the zeroing from calloc (we could split it into
malloc + memset maybe).  redundant store elimination in FRE/DOM
is what elides later stores but those are not set up to pick
up the zero from calloc even ...

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

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

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

--- Comment #5 from Andrew Pinski  ---
Right for aarch64, most people won't use +simd/+nosimd combo (though it might
show up inside the kernel) but they might use +sve/+nosve ...
So the aarch64 bug should be fixed ...

[Bug tree-optimization/102382] Missing optimization for strlen after enable O2 vectorization

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

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

--- Comment #4 from Jakub Jelinek  ---
Not to mention, for calloc like the above where size is non-constant, it
wouldn't know how many there are (it would need some magic for all).
Anyway, even constant number of 0s at the end of string > 1 wouldn't really fit
well into the way how string lengths are invalidated...

[Bug other/78584] Bug in GCC argument parser expandargv

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Component|driver  |other

--- Comment #8 from Andrew Pinski  ---
Fixed in GCC 7 by r7-5168.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

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

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

--- Comment #4 from Kewen Lin  ---
I found i386 port seems doesn't have this issue.

#include 
#include 

typedef union
{
  __m128  x;
  float a[4];
} union128;

#pragma GCC target("sse")
int main() {
  union128 u;
  __m128 a = _mm_set_ps (24.43, 68.346, 43.35, 546.46);
  __m128 b = _mm_set_ps (1.17, 2.16, 3.15, 4.14);
  u.x = _mm_add_ps (a,b);
  printf("u: %f %f %f %f\n", u.a[0], u.a[1],u.a[2],u.a[3]);
  return 0;
}

Command line: -mno-sse -flto

i386 ports seems to initialize all built-ins in bif table.

[Bug middle-end/78333] [5 Regression] always-inline gnu-inline functions break -finstrument-functions

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

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

--- Comment #13 from Andrew Pinski  ---
Just for future reference if anyone goes digging, this also fixes the use case
of -D_FORTIFY_SOURCE=2 and printf inside
__cyg_profile_func_enter/__cyg_profile_func_exit .

[Bug middle-end/78333] [5 Regression] always-inline gnu-inline functions break -finstrument-functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||daniel at totalueberwachung 
dot de

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

[Bug middle-end/51846] Compiled programs suffer from infinite recursion when using -finstrument-functions with optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Dup of bug 78333 in the end.

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

[Bug middle-end/51846] Compiled programs suffer from infinite recursion when using -finstrument-functions with optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||6.2.0
  Known to work||6.3.0, 6.4.0, 7.1.0

--- Comment #5 from Andrew Pinski  ---
Looks like it was fixed in GCC 6.3.0 and GCC 7+.  Looking for the change which
might have fixed this one.

[Bug middle-end/51846] Compiled programs suffer from infinite recursion when using -finstrument-functions with optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #4 from Andrew Pinski  ---
Actually I just noticed -D_FORTIFY_SOURCE=2 was being used 

[Bug middle-end/51846] Compiled programs suffer from infinite recursion when using -finstrument-functions with optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME
  Component|c   |middle-end
   Keywords||wrong-code

--- Comment #3 from Andrew Pinski  ---
I looked and upstream GCC 4.5.3 produces the correct code.

[Bug middle-end/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

[pnewell0705 at gmail dot com via Gcc-bugs]

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

--- Comment #23 from pnewell0705 at gmail dot com ---
To Andrew Pinski:

Thank you for the additional post about the fix

Paul

[Bug ipa/101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))

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

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

--- Comment #8 from Jakub Jelinek  ---
BTW, this one seems to have regressed with
r12-2591-g2e96b5f14e4025691b57d2301d71aa6092ed44bc

[Bug ipa/101941] [12 Regression] Linux kernel build failure due to retaining fnsplit fragment with __attribute__((__error__))

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
For the error attribute I think the fix is easier, at least if the functions
with error attribute wouldn't be conditional in the to be created fnsplit -
just punt on fnsplit in that case.  Because if it isn't inlined back, it would
be an error and in a successful compilation it should be optimized away and so
doesn't need fnsplit.
But I think we can't do that for warning attribute, that is just a warning and
even when we warn, we'll successfully compile it...

[Bug target/31035] x86 GNU/Hurd should include crtfm and dfprules because it uses linux.h

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0

[Bug tree-optimization/102382] Missing optimization for strlen after enable O2 vectorization

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

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #1)
> There's a missed optimization w/o vectorization, strlenopt seems to remove
> the p[0] = '\0' store but not the stores to elements 1 to 3.

strlen pass doesn't have any infrastructure to know that more than one
consecutive byte is known to be zero.  It just notes the string length (certain
number of bytes from some pointer known to be non-0 and then one 0) or
non-terminated (certain number of bytes from some pointer known to be non-0).
So, for calloc it can only record that it returns zero terminated string with
length 0, not how many following bytes are also 0.

So, if we want to optimize these special cases of calloc + stores of zero
afterwards, that is a task for some other pass (doesn't DSE do that?).

[Bug middle-end/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #22 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #20)
> So I was looking into this and it was actually fixed for GCC 4.9.0 (which
> was released back in 2014. I was fixing the up the attachments for easier
> access and moving the Component to a more reasonible one.  I was just
> looking for the patch which would have fixed the bug too.

So this was fixed by r0-125277-gb631d45ac3d9d5 .

[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #14 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:57146bfc2459424c007f4b97f29eef4c600a7b8c

commit r9-9732-g57146bfc2459424c007f4b97f29eef4c600a7b8c
Author: Eric Botcazou 
Date:   Fri Sep 17 10:12:12 2021 +0200

Fix PR rtl-optimization/102306

This is a duplication of volatile loads introduced during GCC 9 development
by the 2->2 mechanism of the RTL combiner.  There is already a substantial
checking for volatile references in can_combine_p but it implicitly assumes
that the combination reduces the number of instructions, which is of course
not the case here.  So the fix teaches try_combine to abort the combination
when it is about to make a copy of volatile references to preserve them.

gcc/
PR rtl-optimization/102306
* combine.c (try_combine): Abort the combination if we are about to
duplicate volatile references.

gcc/testsuite/
* gcc.target/sparc/20210917-1.c: New test.

[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice

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

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

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

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

commit r10-10134-g0c1af84f181237b8a90ae391152dbdcb9c6ab064
Author: Eric Botcazou 
Date:   Fri Sep 17 10:12:12 2021 +0200

Fix PR rtl-optimization/102306

This is a duplication of volatile loads introduced during GCC 9 development
by the 2->2 mechanism of the RTL combiner.  There is already a substantial
checking for volatile references in can_combine_p but it implicitly assumes
that the combination reduces the number of instructions, which is of course
not the case here.  So the fix teaches try_combine to abort the combination
when it is about to make a copy of volatile references to preserve them.

gcc/
PR rtl-optimization/102306
* combine.c (try_combine): Abort the combination if we are about to
duplicate volatile references.

gcc/testsuite/
* gcc.target/sparc/20210917-1.c: New test.

[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:469aad8b5d787c728fbe8b4ec6537385d7815d5a

commit r11-9011-g469aad8b5d787c728fbe8b4ec6537385d7815d5a
Author: Eric Botcazou 
Date:   Fri Sep 17 10:12:12 2021 +0200

Fix PR rtl-optimization/102306

This is a duplication of volatile loads introduced during GCC 9 development
by the 2->2 mechanism of the RTL combiner.  There is already a substantial
checking for volatile references in can_combine_p but it implicitly assumes
that the combination reduces the number of instructions, which is of course
not the case here.  So the fix teaches try_combine to abort the combination
when it is about to make a copy of volatile references to preserve them.

gcc/
PR rtl-optimization/102306
* combine.c (try_combine): Abort the combination if we are about to
duplicate volatile references.

gcc/testsuite/
* gcc.target/sparc/20210917-1.c: New test.

[Bug target/101900] -mtune-ctrl=use_vector_fp_converts,use_vector_converts doesn't work with AVX

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:16cca1806d2ac6f03cdc8942edd8762dab1851c4

commit r12-3614-g16cca1806d2ac6f03cdc8942edd8762dab1851c4
Author: H.J. Lu 
Date:   Wed Sep 15 14:17:58 2021 +0800

x86: Properly handle USE_VECTOR_FP_CONVERTS/USE_VECTOR_CONVERTS

Check TARGET_USE_VECTOR_FP_CONVERTS or TARGET_USE_VECTOR_CONVERTS when
handling avx_partial_xmm_update attribute.  Don't convert AVX partial
XMM register update if vector packed SSE conversion should be used.

gcc/

PR target/101900
* config/i386/i386-features.c (remove_partial_avx_dependency):
Check TARGET_USE_VECTOR_FP_CONVERTS and TARGET_USE_VECTOR_CONVERTS
before generating vxorps.

gcc/testsuite

PR target/101900
* gcc.target/i386/pr101900-1.c: New test.
* gcc.target/i386/pr101900-2.c: Likewise.
* gcc.target/i386/pr101900-3.c: Likewise.

[Bug rtl-optimization/102306] [9/10/11/12 Regression] Volatile pointer dereferenced twice

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:687e30d9d74f5c69a54617147ce3433b07ee59ce

commit r12-3611-g687e30d9d74f5c69a54617147ce3433b07ee59ce
Author: Eric Botcazou 
Date:   Fri Sep 17 10:12:12 2021 +0200

Fix PR rtl-optimization/102306

This is a duplication of volatile loads introduced during GCC 9 development
by the 2->2 mechanism of the RTL combiner.  There is already a substantial
checking for volatile references in can_combine_p but it implicitly assumes
that the combination reduces the number of instructions, which is of course
not the case here.  So the fix teaches try_combine to abort the combination
when it is about to make a copy of volatile references to preserve them.

gcc/
PR rtl-optimization/102306
* combine.c (try_combine): Abort the combination if we are about to
duplicate volatile references.

gcc/testsuite/
* gcc.target/sparc/20210917-1.c: New test.

[Bug tree-optimization/102383] Missing optimization for PRE after enable O2 vectorization

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #4 from Kewen Lin  ---
(In reply to Richard Biener from comment #2)
> The issue is that we tame PRE because it tends to inhibit vectorization.
> 
>   /* Inhibit the use of an inserted PHI on a loop header when
>  the address of the memory reference is a simple induction
>  variable.  In other cases the vectorizer won't do anything
>  anyway (either it's loop invariant or a complicated
>  expression).  */
>   if (sprime
>   && TREE_CODE (sprime) == SSA_NAME
>   && do_pre
>   && (flag_tree_loop_vectorize || flag_tree_parallelize_loops > 1)
>   && loop_outer (b->loop_father)
>   && has_zero_uses (sprime)
>   && bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (sprime))
>   && gimple_assign_load_p (stmt))
> 
> the heuristic would either need to become much more elaborate (do more
> checks whether vectorization is likely) or we could make the behavior
> depend on the cost model as well, for example exclude very-cheap here.
> That might have an influence on the performance benefit seen from
> -O2 default vectorization though.
> 
> IIRC we suggested to enable predictive commoning at -O2 but avoid
> unroll factors > 1 when it was not explicitely enabled.
> 

Yeah, it's PR100794.  I also collected some data for different approaches at
that time.  Recently I opened another issue PR102054 which is also related to
that we restrict PRE due to loop-vect.

[Bug target/102326] ICE in tree_to_uhwi, at tree.c:4520

[pc.wang at linux dot alibaba.com via Gcc-bugs]

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

Pengcheng Wang  changed:

   What|Removed |Added

  Attachment #51459|0   |1
is obsolete||

--- Comment #1 from Pengcheng Wang  ---
Created attachment 51473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51473=edit
V2 patch

[Bug middle-end/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

[pnewell0705 at gmail dot com via Gcc-bugs]

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

--- Comment #21 from pnewell0705 at gmail dot com ---
Andrew Pinski:

Thank you for the reply so I understand what happened

Best,
Paul

[Bug middle-end/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

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

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

--- Comment #20 from Andrew Pinski  ---
(In reply to pnewell0705 from comment #19)
> To "Pinskia" and/or whoever:
> 
> The last entry on this issue was in 2011. Tonight, in 2021, I have just
> gotten 5 emails that imply "something is happening". I open the bugzilla and
> there are no new comments. I do a bit of checking and "something has changed
> that I wasn't aware of ... I am suddenly no longer on the cc-list. With all
> due respect, I was back in 2021.

So I was looking into this and it was actually fixed for GCC 4.9.0 (which was
released back in 2014. I was fixing the up the attachments for easier access
and moving the Component to a more reasonible one.  I was just looking for the
patch which would have fixed the bug too.

[Bug tree-optimization/102384] Missing optimization for pcom after enable O2 vectorization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
The issue also exists for -O3.

__attribute__((noinline))
void foo4 (int * a)
{
  int * _20;

   [local count: 10737416]:
  _20 = a_10(D) + 12;
  __builtin_memset (_20, 255, 400);
  __builtin_memset (a_10(D), 0, 400); [tail call]
  return;

}

[Bug middle-end/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

[pnewell0705 at gmail dot com via Gcc-bugs]

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

--- Comment #19 from pnewell0705 at gmail dot com ---
To "Pinskia" and/or whoever:

The last entry on this issue was in 2011. Tonight, in 2021, I have just gotten
5 emails that imply "something is happening". I open the bugzilla and there are
no new comments. I do a bit of checking and "something has changed that I
wasn't aware of ... I am suddenly no longer on the cc-list. With all due
respect, I was back in 2021.

I am re-adding myself to the cc list but need to make the request that I get an
update as to what the flurry is tonight.

I also note that every email gotten tonight is a "change in status" with no
comments 

My thanks in advance,
Paul

[Bug tree-optimization/102382] Missing optimization for strlen after enable O2 vectorization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
The issue also exists for -O3

[Bug tree-optimization/102383] Missing optimization for PRE after enable O2 vectorization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
The issue also exists for -O3

[Bug middle-end/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

[pnewell0705 at gmail dot com via Gcc-bugs]

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

pnewell0705 at gmail dot com changed:

   What|Removed |Added

 CC||pnewell0705 at gmail dot com

--- Comment #18 from pnewell0705 at gmail dot com ---
To "Pinskia" and/or whoever:

The last entry on this issue was in 2011. Tonight, in 2021, I have just gotten
5 emails that imply "something is happening". I open the bugzilla and there are
no new comments. I do a bit of checking and "something has changed that I
wasn't aware of ... I am suddenly no longer on the cc-list. With all due
respect, I was back in 2021.

I am re-adding myself to the cc list but need to make the request that I get an
update as to what the flurry is tonight.

I also note that every email gotten tonight is a "change in status" with no
comments 

My thanks in advance,
Paul

[Bug ipa/102361] Errors compiling Linux kernel 5.14 with CONFIG_FORTIFY=y

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

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

--- Comment #14 from Andrew Pinski  ---
(In reply to DAC324 from comment #13)
> Sorry for duplicate reporting. For me, the error message 
> Please apologize for the inconvenience. 
It is ok, it is good that you filed the bug.  I have been doing a lot of
cleanup of GCC's bugzilla lately so I have some memory of some of the more
recent bugs filed.  Searching bugzilla to know if there was a dup filed is a
huge task even so I don't think most people will be doing it.

[Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tr

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
Summary|ICE: in single_pred_edge,   |[12 Regression] ICE: in
   |at basic-block.h:350 under  |single_pred_edge, at
   |"-O2 -fno-toplevel-reorder  |basic-block.h:350 under
   |-fno-tree-ch -fno-tree-dce  |"-O2 -fno-toplevel-reorder
   |-fno-tree-dominator-opts|-fno-tree-ch -fno-tree-dce
   |-fno-tree-dse   |-fno-tree-dominator-opts
   |-fno-tree-loop-ivcanon  |-fno-tree-dse
   |-fpredictive-commoning" |-fno-tree-loop-ivcanon
   ||-fpredictive-commoning"
   Keywords||ice-on-valid-code,
   ||needs-bisection, wrong-code
   Last reconfirmed||2021-09-17
   Target Milestone|--- |12.0

--- Comment #1 from Richard Biener  ---
Huh, the code is odd:

  basic_block exit_bb = single_pred (loop->latch);
  new_exit = find_edge (exit_bb, rest);
  new_exit->probability = profile_probability::always ()
.apply_scale (1, new_est_niter + 1);

but here we have a diamond after the block that exits the loop and thus
neither a single predecessor of the latch nor would that be something
resembling an exit block.  It looks like the code might have wanted
to use single_pred (rest) here plus eventually splitting the exit
edge in case it didn't have a single predecessor.

Richard, you refactored this, so likely caused this.

[Bug c/48730] static function scope not honored by -fms-extensions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-17
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug ipa/102361] Errors compiling Linux kernel 5.14 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #13 from DAC324  ---
Sorry for duplicate reporting. For me, the error message 

'__write_overflow' declared with attribute error: detected write beyond size of
object passed as 1st parameter

and its counterpart 

'__read_overflow2' declared with attribute error: detected read beyond size of
object passed as 2nd parameter

did not point me to using 

fnsplit fragment with __attribute__((__error__))

as a correct search term, in the first instance.
Please apologize for the inconvenience. 

Just FYI (although I assume you know this already):

With CONFIG_FORTIFY=n, you will be able to build the kernel but it will not run
satisfactorily, if able to boot at all.

[Bug tree-optimization/102385] New: ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-loop-ivc

[suochenyao at 163 dot com via Gcc-bugs]

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

Bug ID: 102385
   Summary: ICE: in single_pred_edge, at basic-block.h:350 under
"-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce
-fno-tree-dominator-opts -fno-tree-dse
-fno-tree-loop-ivcanon -fpredictive-commoning"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suochenyao at 163 dot com
  Target Milestone: ---

***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
short a, b;
int c[9];
void(d)() {}
void e() {
  a = 0;
  for (; a <= 4; a++) {
short *f = 
c[a] || (*f = 0);
d(c[a + 2]);
  }
}
int main() {return 0;}
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/data/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/data/bin/gcc-dev --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210916 (experimental) (GCC)

git version: 745781d24cd7562202687cfbe05597ee673d4537
***
Command Lines:
$ gcc -Wall -Wextra -O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce
-fno-tree-dominator-opts -fno-tree-dse -fno-tree-loop-ivcanon
-fpredictive-commoning a.c
during GIMPLE pass: pcom
a.c: In function ‘e’:
a.c:4:6: internal compiler error: in single_pred_edge, at basic-block.h:350
4 | void e() {
  |  ^
0x773ee4 single_pred_edge
../../gcc/basic-block.h:350
0x77461d single_pred_edge
../../gcc/sbitmap.h:105
0x77461d tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
../../gcc/tree-ssa-loop-manip.c:1295
0xf525c8 pcom_worker::tree_predictive_commoning_loop(bool)
../../gcc/tree-predcom.c:3401
0xf52aa4 tree_predictive_commoning(bool)
../../gcc/tree-predcom.c:3428
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/45643] Enhancement to disable debugging symbols with pragma/attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|c   |c++

[Bug tree-optimization/102384] Missing optimization for pcom after enable O2 vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-17

--- Comment #1 from Richard Biener  ---
The issue is that we have no way to express the data dependence of these
partial overlapping stores and since predcom works with data dependences
there's nothing to do.

[Bug c/38679] semantics of assignment in a return statement suspect

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Keywords||wrong-code

--- Comment #2 from Andrew Pinski  ---
This changed in GCC 4.6.0 with r0-102336 which also clarify the documentation
on volatile so fixed for GCC 4.6.0.

[Bug tree-optimization/102383] Missing optimization for PRE after enable O2 vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-17

--- Comment #2 from Richard Biener  ---
The issue is that we tame PRE because it tends to inhibit vectorization.

  /* Inhibit the use of an inserted PHI on a loop header when
 the address of the memory reference is a simple induction
 variable.  In other cases the vectorizer won't do anything
 anyway (either it's loop invariant or a complicated
 expression).  */
  if (sprime
  && TREE_CODE (sprime) == SSA_NAME
  && do_pre
  && (flag_tree_loop_vectorize || flag_tree_parallelize_loops > 1)
  && loop_outer (b->loop_father)
  && has_zero_uses (sprime)
  && bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (sprime))
  && gimple_assign_load_p (stmt))

the heuristic would either need to become much more elaborate (do more
checks whether vectorization is likely) or we could make the behavior
depend on the cost model as well, for example exclude very-cheap here.
That might have an influence on the performance benefit seen from
-O2 default vectorization though.

IIRC we suggested to enable predictive commoning at -O2 but avoid
unroll factors > 1 when it was not explicitely enabled.

Note that the issue for this testcase is that w/o PRE the predcom
behaves differently (but the testcase comment suggests that we'd
have to undo PRE).