[Bug target/106488] New: [13 Regression] ICE: in ix86_output_ssemov, at config/i386/i386.cc:5565 with -O2 -fno-dce -fno-tree-vrp -mf16c -fno-tree-coalesce-vars

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106488
   Summary: [13 Regression] ICE: in ix86_output_ssemov, at
config/i386/i386.cc:5565 with -O2 -fno-dce
-fno-tree-vrp -mf16c -fno-tree-coalesce-vars
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-tree-vrp -mf16c
-fno-tree-coalesce-vars testcase.c -Wno-psabi
during RTL pass: final
testcase.c: In function 'foo':
testcase.c:16:1: internal compiler error: in ix86_output_ssemov, at
config/i386/i386.cc:5565
   16 | }
  | ^
0x82ca5f ix86_output_ssemov(rtx_insn*, rtx_def**)
/repo/gcc-trunk/gcc/config/i386/i386.cc:5565
0xfe6ba3 final_scan_insn_1
/repo/gcc-trunk/gcc/final.cc:2826
0xfe732b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.cc:2939
0xfe74d4 final_1
/repo/gcc-trunk/gcc/final.cc:1996
0xfe81a8 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4284
0xfe81a8 execute
/repo/gcc-trunk/gcc/final.cc:4364
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug fortran/106487] Calls to ___builtin_nested_func_ptr_created that cannot be resolved on M1 (Apple silicon)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
There is a github issue related to this already and this is not a fsf gcc
release.

[Bug fortran/106487] New: Calls to ___builtin_nested_func_ptr_created that cannot be resolved on M1 (Apple silicon)

[apersaud at lbl dot gov via Gcc-bugs]

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

Bug ID: 106487
   Summary: Calls to ___builtin_nested_func_ptr_created that
cannot be resolved on M1 (Apple silicon)
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: apersaud at lbl dot gov
  Target Milestone: ---

I'm trying to compile a program (not public available) on an M1 and am running
in an issue where the linker is complaining about unknown functions

U ___builtin_nested_func_ptr_created
U ___builtin_nested_func_ptr_deleted

I'm using:

> gfortran-12 --version
GNU Fortran (Homebrew GCC 12.1.0_1) 12.1.0
[...]

Since I cannot share the source code. I tried to reduce it to a small program:
"""
MODULE focus
  IMPLICIT NONE
  PRIVATE

  PUBLIC  myinit
  ABSTRACT INTERFACE
 REAL(kind=8) FUNCTION dummyf(x)
   REAL(kind=8), INTENT(IN) :: x
 END FUNCTION dummyf
  end INTERFACE

CONTAINS

  SUBROUTINE myfun(fun,  x, res)
! return res = fun(x)
IMPLICIT NONE
PROCEDURE(dummyf) :: fun
REAL(kind=8), INTENT(INOUT) :: x
INTEGER, INTENT(OUT) :: res
res = fun(x)
  end SUBROUTINE myfun

  SUBROUTINE myinit()
IMPLICIT NONE
INTEGER :: its, nfcalls
REAL(kind=8) :: ftv

CALL myfun(internal_func,  ftv,  its)
  CONTAINS
FUNCTION internal_func(fv)
  IMPLICIT NONE
  REAL(kind=8), INTENT(IN) :: fv
  REAL(kind=8) :: internal_func
  !internal_func = nfcalls   ! create links to
___builtin_nested_func_ptr_created
  internal_func = 111! this works
END FUNCTION internal_func
  END SUBROUTINE myinit

END MODULE focus
"""

The problem seems to be the function definition in the contains block of a
subroutine.
However, if this is not working on the M1, I would have expected some kind of
warning or error message, but the file compiles OK and only fails in a later
linker stage when the two mentioned functions cannot be found.

The command I used to compile was 
"gfortran-12 -m64 -O2 -c input.f95"

When I comment out the "internal_func = nfcalls" line and uncomment the
following line, the compiler does not link to these two functions (this only
works with the -O2 flag enabled though, so it probably just inlines the
function calls and therefore there is no CONTAINS block anymore?)

I'm not that familiar with fortran/gfortran...Not sure if this can/should be
fixed, but I thought I report it.

[Bug c++/71954] template partial specialization for constexpr error

[lichray at gmail dot com via Gcc-bugs]

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

Zhihao Yuan  changed:

   What|Removed |Added

 CC||lichray at gmail dot com

--- Comment #5 from Zhihao Yuan  ---
Please fix. The workaround is to write

struct Struct {
template 
constexpr static bool use_cond = false;
};

template 
constexpr bool Struct::use_cond = true;

But when the enclosing context is a class template, writing such a partial
specialization will be very tedious.

[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #6 from Kees Cook  ---
(In reply to Richard Biener from comment #5)
> Should be fixed on trunk.  Can you check on the original unreduced testcase?

Thanks! I've done test builds and can confirm these two false positives have
been eliminated:

arch/x86/kvm/emulate.c:251:27: warning: array subscript 32 is above array
bounds of 'long unsigned int[17]' [-Warray-bounds]
arch/x86/kvm/ioapic.c:213:33: warning: array subscript 32 is above array bounds
of 'union kvm_ioapic_redirect_entry[24]' [-Warray-bounds]

Is this backportable to gcc 12?

[Bug c++/106486] C++ warning for -Wmissing-prototypes is pure nuisance

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

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

--- Comment #1 from Andrew Pinski  ---
> which is often painful to do without structural Makefile changes.

Not true. Most makefiles have CFLAGS and CXXFLAGS. And then use a common
OPTFLAGS or something similar. It seems like setting CXXFLAGS directly to
CFLAGS is wrong.

[Bug c++/106486] New: C++ warning for -Wmissing-prototypes is pure nuisance

[hpa at zytor dot com via Gcc-bugs]

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

Bug ID: 106486
   Summary: C++ warning for -Wmissing-prototypes is pure nuisance
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

Since upgrading to gcc 12.1.1, I keep getting the following warning through
various projects:

cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for
C/ObjC but not for C++

This warning is pure nuisance. In a mixed-language project it is *extra*
important that the right prototypes are used, and it is far easier to enable
-Wmissing-prototypes project wide. This warning implies that one would have to
conditionalize the -W options based on the language of an input file, which is
often painful to do without structural Makefile changes.

Note that there doesn't seem to be any way to squelch this warning, either
(e.g. a -Wno-warning-not-applicable option or similar.)
cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for
C/ObjC but not for C++

[Bug target/106484] Failure to optimize uint64_t/constant division on ARM32

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/106485] Can't use heap pointer in `static_assert`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105826

--- Comment #1 from Andrew Pinski  ---
I think this is a dup of bug 105826.

[Bug c++/105619] Wrong "used in its own initializer" with class prvalue

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64989

--- Comment #2 from Andrew Pinski  ---
I think this is a dup of bug 64989.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #11 from Roger Sayle  ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599095.html

[Bug c++/106485] New: Can't use heap pointer in `static_assert`

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 106485
   Summary: Can't use heap pointer in `static_assert`
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/W4r6oMa3M.

```C++
struct I {
  int* i = new int{1};
  constexpr ~I() { delete i; }
};
static_assert([] { return I{}.i; }());
static_assert(I{}.i);
```

```
:5:19: error: non-constant condition for static assertion
5 | static_assert(I{}.i);
  |   ^
:5:19: error: the value of '' is not usable in a constant
expression
:5:17: note: '' was not declared 'constexpr'
5 | static_assert(I{}.i);
  | ^
Compiler returned: 1
```

It works wrapped in an IILE, or if the `int` is uninitialized.

[Bug target/106484] Failure to optimize uint64_t/constant division on ARM32

[rsaxvc at gmail dot com via Gcc-bugs]

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

rsaxvc at gmail dot com changed:

   What|Removed |Added

 CC||rsaxvc at gmail dot com

--- Comment #1 from rsaxvc at gmail dot com ---
Created attachment 53388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53388=edit
example umulh implementation

C implementation of umulh which can be used to optimize uint64_t/constant
division on 32-bit processors without a umulh instruction but with a
32x32=64bit multiplier.

[Bug target/106484] New: Failure to optimize uint64_t/constant division on ARM32

[rsaxvc at gmail dot com via Gcc-bugs]

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

Bug ID: 106484
   Summary: Failure to optimize uint64_t/constant division on
ARM32
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsaxvc at gmail dot com
  Target Milestone: ---
Target: arm

The following test function compiles into a call to __aeabi_uldivmod, even
though the divisor is a constant. Here's an example function:

#include 
uint64_t ns_to_s( uint64_t ns64 )
{
return ns64 / 10ULL;
}

CortexM4(-O3 -Wall -Wextra -mcpu=cortex-m4) assembly:

ns_to_s(unsigned long long):
push{r3, lr}
adr r3, .L4
ldrdr2, [r3]
bl  __aeabi_uldivmod
pop {r3, pc}
.L4:
.word   10
.word   0

Interestingly, gcc 12.1 for aarch64 compiles the above C function by
implementing division by a constant with scaled multiplication by the inverse
using the umulh instruction(not present on 32-bit ARM). (-O3 -Wall -Wextra):

ns_to_s(unsigned long):
mov x1, 23123
lsr x0, x0, 9
movkx1, 0xa09b, lsl 16
movkx1, 0xb82f, lsl 32
movkx1, 0x44, lsl 48
umulh   x0, x0, x1
lsr x0, x0, 11
ret

Instead, if something like __umulh could be added to libgcc, then GCC could use
the constants generated in the aarch64 logic to implement uint64_t/constant
division. Example umulh approach is attached. On Cortex-M4, the umulh-based
approach is significantly faster, although this depends on the specific libc
__aeabi_uldivmod linked against as well as the numerator.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[schwab--- via Gcc-bugs]

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

--- Comment #10 from Andreas Schwab  ---
libbacktrace and libphobos are target modules that are part of the bootstrap
stages.  libgo and libgfortran are target modules that are _not_ part of the
bootstrap stages.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
toplevel Makefile.in has:
all-target-libphobos: maybe-all-target-libbacktrace
and
all-target-libgo: maybe-all-target-libbacktrace
configure-target-libgfortran: maybe-all-target-libbacktrace
but unlike the first one, the latter two are surrounded by
@unless gcc-bootstrap
...
@endunless gcc-bootstrap
and when bootstrap isn't disabled they don't appear in toplevel Makefile.
What causes that difference, no idea.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #8 from Roger Sayle  ---
Investigating further, using an absolute path doesn't help, but interestingly
after the failure, repeatedly trying "make -j 8 bootstrap" a few times, allows
the build to progress after several attempts, so it looks like a race condition
issue, caused by a missing (serializing) dependency.

[Bug c++/106483] undefined reference to function implemented in shared library if putting main.cpp after options, but non of any error when putting before options

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Firstly, this is the linker doing this, not GCC. GCC just passes the arguments
to the linker in the order you specify them.

Secondly, this is the correct behaviour. Your linker is set up to default to
--as-needed which means that shared libraries on the command line will only get
used if they satisfy a non-weak undefined reference from a regular object file
that has already been processed by the linker. If you put -ladd before main.cpp
then there are no undefined symbols yet, so the library is just ignored.

https://web.archive.org/web/20210609020437/c-faq.com/lib/libsearch.html

Either link with -Wl,--no-as-needed to change the linker's behaviour so that
shared libraries are always used, or put the libraries in the right order.

[Bug c++/106483] New: undefined reference to function implemented in shared library if putting main.cpp after options, but non of any error when putting before options

[xyang619 at 126 dot com via Gcc-bugs]

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

Bug ID: 106483
   Summary: undefined reference to function implemented in shared
library if putting main.cpp after options, but non of
any error when putting before options
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xyang619 at 126 dot com
  Target Milestone: ---

GCC version and OS: gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Code example to reproduce the bugs:
#add.h
int add(int, int);

#add.cpp

#include "add.h"
int add(int a, int b) {
return a+b;
}

#main.cpp
#include "add.h"
#include 
int main() {
int a=2;
int b=3;
int c=add(a,b);
printf("%d\n", c);
return 0;
}

#first, compile add.cpp to shared library, it works well
g++ -Wall -fPIC -shared -o libadd.so add.cpp

#second, compile main.cpp and link with the libadd.so, it will produce error as
followed:
g++ -Wall -L. -ladd -o add_main main.cpp
/usr/bin/ld: /tmp/ccCzqGbU.o: in function `main':
main.cpp:(.text+0x21): undefined reference to `add(int, int)'
collect2: error: ld returned 1 exit status

#however, if I put the main.cpp before the options, it works well
g++ main.cpp -Wall -L. -ladd -o add_main

[Bug target/101438] Compiler hang on inline asm with local register and alloca

[andrey.vihrov at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Andrey Vihrov  ---
Looks like this is a duplicate of bug 105032 (or vice versa).

Both samples from this bug succeed for me with GCC 11.3 and GCC 12.

[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33

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

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

--- Comment #6 from Jakub Jelinek  ---
And on the box I was working on this fix (Fedora 34, glibc 2.33) without the
fix I see in ../configure --enable-languages=c,c++,fortran
--with-long-double-format=ieee --with-long-double-128
make check-gfortran RUNTESTFLAGS='dg.exp=boz* c-interop.exp'
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/c-interop/c-interop.exp ...
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/boz_15.f90   -O0  execution test
FAIL: gfortran.dg/boz_15.f90   -O1  execution test
FAIL: gfortran.dg/boz_15.f90   -O2  execution test
FAIL: gfortran.dg/boz_15.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/boz_15.f90   -O3 -g  execution test
FAIL: gfortran.dg/boz_15.f90   -Os  execution test

=== gfortran Summary ===

# of expected passes1963
# of unexpected failures6
# of unsupported tests  12
and with the change:
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/c-interop/c-interop.exp ...
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/dg.exp ...

=== gfortran Summary ===

# of expected passes1969
# of unsupported tests  12

For the latter

PASS: gfortran.dg/c-interop/allocatable-dummy.f90   -Os  execution test
CFI_allocate: Base address of C descriptor must be NULL.
CFI_allocate: The object of the C descriptor must be a pointer or allocatable
variable.
CFI_deallocate: Base address is already NULL.
PASS: gfortran.dg/c-interop/allocate-errors.f90   -O0  execution test
PASS: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90   -O1 
execution test
PASS: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90   -O2 
(test for excess errors)




PASS: gfortran.dg/c-interop/cf-descriptor-3.f90   -O2  execution test
,
   ]>
,
   ]>
,
   ]>
PASS: gfortran.dg/c-interop/cf-descriptor-7.f90   -Os  execution test
]>
]>
]>
]>
PASS: gfortran.dg/c-interop/contiguous-3.f90   -O0  execution test
in the log.  So, I can't really reproduce the above.

Not really clear how it could be related though, e.g. contiguous-3.f90 doesn't
have anything real/complex related in it.
C_LONG_DOUBLE is only present in typecodes-array-longdouble.f90 and
typecodes-scalar-longdouble.f90.

[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33

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

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

--- Comment #5 from Jakub Jelinek  ---
Strange, in my 12 branch distro (scratch) build the only differences with the
patch are:
-FAIL: gfortran.dg/boz_15.f90   -O0  execution test
-FAIL: gfortran.dg/boz_15.f90   -O1  execution test
-FAIL: gfortran.dg/boz_15.f90   -O2  execution test
-FAIL: gfortran.dg/boz_15.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
-FAIL: gfortran.dg/boz_15.f90   -O3 -g  execution test
-FAIL: gfortran.dg/boz_15.f90   -Os  execution test
and nothing else.

[Bug debug/106261] [10/11 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in output_call_frame_info,  |output_call_frame_info, at
   |at dwarf2out.cc:943 |dwarf2out.cc:943

--- Comment #7 from Jakub Jelinek  ---
Fixed for 12.2+ too.

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

--- Comment #13 from Jakub Jelinek  ---
Fixed for 12.2+ too.

[Bug bootstrap/106482] New: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors

[skunk at iskunk dot org via Gcc-bugs]

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

Bug ID: 106482
   Summary: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails
with C++ errors
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

I attempted to bootstrap 12.1.0 using GCC 4.8.2. The documented prerequisites
include an "ISO C++11 compiler," so this appears to be a supported arrangement.

GCC 12 was configured with --disable-shared --disable-nls
--enable-version-specific-runtime-libs --with-pic --disable-multilib
--with-arch=opteron --disable-libcc1 --enable-languages=c,c++,lto

The bootstrap failed as shown below. I was able to bootstrap 10.2.0 using the
original compiler, and then bootstrapped 12.1.0 with that intermediary.


tg-g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/src/gcc-12.1.0/gcc
-I/home/src/gcc-12.1.0/gcc/. -I/home/src/gcc-12.1.0/gcc/../include
-I/home/src/gcc-12.1.0/gcc/../libcpp/include
-I/home/src/gcc-12.1.0/gcc/../libcody -I/home/sfw/arch/linux64/include
-I/home/sfw/arch/linux64/include -I/home/sfw/arch/linux64/include 
-I/home/src/gcc-12.1.0/gcc/../libdecnumber
-I/home/src/gcc-12.1.0/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/src/gcc-12.1.0/gcc/../libbacktrace   -o fwprop.o -MT fwprop.o -MMD -MP
-MF ./.deps/fwprop.TPo /home/src/gcc-12.1.0/gcc/fwprop.cc
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:24:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::get_child(typename Accessors::node_type, unsigned
int)' does not match any in class 'base_splay_tree'
 base_splay_tree::get_child (node_type node, unsigned int index)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:125:20: error: candidate is: static
typename Accessors::node_type base_splay_tree::get_child(typename
Accessors::node_type, unsigned int)
   static node_type get_child (node_type, unsigned int);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:49:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::promote_child(typename Accessors::node_type,
unsigned int)' does not match any in class 'base_splay_tree'
 base_splay_tree::promote_child (node_type node, unsigned int index)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:128:15: error: candidates are:
static void base_splay_tree::promote_child(typename
Accessors::node_type, unsigned int, typename Accessors::node_type)
   static void promote_child (node_type, unsigned int, node_type);
   ^
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:127:20: error:
static typename Accessors::node_type
base_splay_tree::promote_child(typename Accessors::node_type,
unsigned int)
   static node_type promote_child (node_type, unsigned int);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:187:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::splay_limit(typename Accessors::node_type)' does
not match any in class 'base_splay_tree'
 base_splay_tree::splay_limit (node_type start)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:131:20: error: candidate is:
template template static typename
Accessors::node_type base_splay_tree::splay_limit(typename
Accessors::node_type)
   static node_type splay_limit (node_type);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from 

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

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

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

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

https://gcc.gnu.org/g:681c73db9bd156f9b65a73ccc6c4a0a697fe70d6

commit r12-8645-g681c73db9bd156f9b65a73ccc6c4a0a697fe70d6
Author: Jakub Jelinek 
Date:   Fri Jul 29 09:49:11 2022 +0200

openmp: Fix up handling of non-rectangular simd loops with pointer type
iterators [PR106449]

There were 2 issues visible on this new testcase, one that we didn't have
special POINTER_TYPE_P handling in a few spots of expand_omp_simd - for
pointers we need to use POINTER_PLUS_EXPR and need to have the non-pointer
part in sizetype, for non-rectangular loop on the other side we can rely on
multiplication factor 1, pointers can't be multiplied, without those
changes
we'd ICE.  The other issue was that we put n2 expression directly into a
comparison in a condition and regimplified that, for the [512] case that
and with gimplification being destructed that unfortunately meant
modification
of original fd->loops[?].n2.  Fixed by unsharing the expression.  This was
causing a runtime failure on the testcase.

2022-07-29  Jakub Jelinek  

PR middle-end/106449
* omp-expand.cc (expand_omp_simd): Fix up handling of pointer
iterators in non-rectangular simd loops.  Unshare fd->loops[i].n2
or n2 before regimplifying it inside of a condition.

* testsuite/libgomp.c-c++-common/pr106449.c: New test.

(cherry picked from commit 97d32048c04e9787fccadc4bae1c042754503e34)

[Bug debug/106261] [10/11/12 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943

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

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

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

https://gcc.gnu.org/g:0062d8491c20eb95411ac0b112e09ec0cee836d1

commit r12-8644-g0062d8491c20eb95411ac0b112e09ec0cee836d1
Author: Jakub Jelinek 
Date:   Wed Jul 27 12:06:22 2022 +0200

cgraphunit: Don't emit asm thunks for -dx [PR106261]

When -dx option is used (didn't know we have it and no idea what is it
useful for), we just expand functions to RTL and then omit all further
RTL passes, so the normal functions aren't actually emitted into assembly,
just variables.
The following testcase ICEs, because we don't emit the methods, but do
emit thunks pointing to that and those thunks have unwind info and rely on
at least some real functions to be emitted (which is normally the case,
thunks are only emitted for locally defined functions) because otherwise
there are no CIEs, only FDEs and dwarf2out is upset about it.

The following patch fixes that by not emitting assembly thunks for -dx
either.

2022-07-27  Jakub Jelinek  

PR debug/106261
* cgraphunit.cc (cgraph_node::assemble_thunks_and_aliases): Don't
output asm thunks for -dx.

* g++.dg/debug/pr106261.C: New test.

(cherry picked from commit f9671b60f9395cb1dca128b92f5dd215f5aeaae1)

[Bug middle-end/106144] wide_int shifted_mask() and mask() do not agree

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

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

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

https://gcc.gnu.org/g:527dccb33e54ffe49fb1507fc4539968f48a9d12

commit r12-8643-g527dccb33e54ffe49fb1507fc4539968f48a9d12
Author: Jakub Jelinek 
Date:   Fri Jul 1 11:17:41 2022 +0200

wide-int: Fix up wi::shifted_mask [PR106144]

As the following self-test testcase shows, wi::shifted_mask sometimes
doesn't create canonicalized wide_ints, which then fail to compare equal
to canonicalized wide_ints with the same value.
In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec
128,
while wi::shifted_mask (0, 128, false, 128) gives { -1, -1 } with len 2
and prec 128.
The problem is that the code is written with the assumption that there are
3 bit blocks (or 2 if start is 0), but doesn't consider the possibility
where there are 2 bit blocks (or 1 if start is 0) where the highest block
isn't present.  In that case, there is the optional block of negate ? 0 :
-1
elts, followed by just one elt (either one from the if (shift) or just
negate ? -1 : 0) and the rest is implicit sign-extension.
Only if end < prec there is 1 or more bits above it that have different bit
value and so we need to emit all the elts till end and then one more elt.

if (end == prec) would work too, because we have:
  if (width > prec - start)
width = prec - start;
  unsigned int end = start + width;
so end is guaranteed to be end <= prec, dunno what is preferred.

2022-07-01  Jakub Jelinek  

PR middle-end/106144
* wide-int.cc (wi::shifted_mask): If end >= prec, return right
after
emitting element for shift or if shift is 0 first element after
start.
(wide_int_cc_tests): Add tests for equivalency of wi::mask and
wi::shifted_mask with 0 start.

(cherry picked from commit e52592073f6df3d7a3acd9f0436dcc32a8b7493d)

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #7 from Roger Sayle  ---
At the point that this fails there is no
/home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libbacktrace directory whilst
the build (make) is in /home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libgo
I also don't use any "make -j N ..." flags, i.e. a purely sequential build,
so somewhere/somehow libgo is being built before libbacktrace ["-j" might 
also explain why the missing dependency isn't osbserved by everybody].

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[schwab--- via Gcc-bugs]

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

--- Comment #6 from Andreas Schwab  ---
So what's the contents of .../x86_64-pc-linux-gnu/libbacktrace?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-30
 Status|UNCONFIRMED |NEW
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1

--- Comment #5 from Roger Sayle  ---
I see the same problem, building out of the source tree on x86_64-pc-linux-gnu
with GNU make 3.82.  I thought it was a (long standing) known issue, like in PR
104290, but it looks like some folks see this and others don't.  Odd.

make[4]: *** No rule to make target `../libbacktrace/libbacktrace.la', needed
by `libgo.la'.  Stop.
make[4]: Leaving directory `/home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libgo'

configured with:
../gcc/configure --enable-languages=go

Perhaps it's using relative rather than absolute paths to configure?

[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #10 from Zdenek Sojka  ---
Thank you for the patch; I can still trigger the ICE with a degenerate testcase
though:

$ cat testcase.c
void
foo (void)
{
  for (unsigned i = 0; i == 0; i++)
__builtin_printf ("%d", i);
}
$ x86_64-pc-linux-gnu-gcc -O -fharden-compares -fno-tree-forwprop -fno-tree-ch
-fno-tree-dominator-opts -fno-tree-ccp -funreachable-traps
--param=scev-max-expr-size=1 testcase.c 
during GIMPLE pass: optimized
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in execute_todo, at passes.cc:2140
2 | foo (void)
  | ^~~
0x75616a execute_todo
/repo/gcc-trunk/gcc/passes.cc:2140
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/106481] [13 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6884 with -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Last reconfirmed||2022-07-30
 Status|UNCONFIRMED |ASSIGNED
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #1 from Roger Sayle  ---
More TImode STV fallout.  This time with REG_EQUAL notes containing VOIDmode
(implicitly TImode) const_wide_int not being converted to explicit V1TImode
const_vector.  I'm bootstrapping and regression testing a fix.
[Thanks again to Zdenek]

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

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #7 from Sam James  ---
Thanks Dave. I'd seen this failure when testing glibc 2.36 but hadn't looked
into it more (too warm to keep machine on).

[Bug target/68485] ICE while building gpsd package on microblaze

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #12 from Sam James  ---
Ajit doesn't seem to have a Bugzilla account.

[Bug target/106481] New: [13 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6884 with -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106481
   Summary: [13 Regression] ICE: in native_encode_rtx, at
simplify-rtx.cc:6884 with -O2 -fno-dce
-fno-forward-propagate -fno-rerun-cse-after-loop
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-forward-propagate
-fno-rerun-cse-after-loop testcase.c -Wno-psabi
testcase.c:13:1: internal compiler error: in native_encode_rtx, at
simplify-rtx.cc:6884
   13 | }
  | ^
0x7857b6 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
/repo/gcc-trunk/gcc/simplify-rtx.cc:6884
0x16f2feb optimize_constant_pool
/repo/gcc-trunk/gcc/varasm.cc:4437
0x16fcbff output_shared_constant_pool()
/repo/gcc-trunk/gcc/varasm.cc:4544
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.

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