[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |c
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-31
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed reduced testcase:
void f (void *q)
{
  __extension__ int *p1 = q;
}

At first I thought it was an issue with the statement expression but nope, it
is just __extension__ vs -Wc++-compat .

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|diagnostic  |documentation

--- Comment #4 from Andrew Pinski  ---
__extension__ disables all compatibility warnings.

This is by design really as headers sometimes needs to be written using C code
and need to turn off these warnings. 

The documentation should mention that though like it does for -Wc90-c99-compat
, -Wc99-c11-compat and -Wc11-c2x-compat .

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wc_002b_002b-compat

[Bug tree-optimization/105495] `__atomic_compare_exchange` prevents tail-call optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization

--- Comment #6 from Andrew Pinski  ---
I wonder if we could add some access attribute such that the 2nd argument of
__atomic_compare_exchange_4 is marked as read only ...

[Bug c++/105494] syntax error with requires { []{}(); };

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
More likely a dup of bug 103212.

[Bug c++/103212] requires expression with lambda inside causes a parse error

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||12.1.0
  Known to work||12.2.0
   Keywords||needs-bisection

--- Comment #3 from Andrew Pinski  ---
Looks like this has been fixed.

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

[helmut at subdivi dot de via Gcc-bugs]

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

Helmut Grohne  changed:

   What|Removed |Added

 CC||helmut at subdivi dot de

--- Comment #2 from Helmut Grohne  ---
Created attachment 53801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53801&action=edit
proposed fix

I confirm the issue on gcc 12.2.0-3 on Debian and have seen it since at least
version 11. The symptom is slightly different though. It no longer produces an
ICE. Instead the output looks like this:

lastincdir/testcase.h:1:24: error: no include path in which to search for
doesnotexist.h
...
(null):0: confused by earlier errors, bailing out

The invocation terminates with status 1.

While this no longer is an ICE, the behavior is not correct either.
__has_include_next should not error out and return false-ish instead.

I believe that looking at the attached patch makes the problem fairly obvious.

This problem now affects toolchain bootstrap on Debian for hurd architectures.
The stage1 preprocessor happens to run into this very early.

[Bug fortran/107362] Segfault for recursive class

[federico.perini at gmail dot com via Gcc-bugs]

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

federico  changed:

   What|Removed |Added

 CC||federico.perini at gmail dot 
com

--- Comment #2 from federico  ---
I'm getting the same issue on a recursive tree structure, I will post my
testcase here instead of opening a new bug. 
I see a segfault in the default finalizer (I think it gets called when a
recursive type is returned as a function result).

I get the segfault on the default finalization routine with all gfortran
versions, 7.1 to 12.1. 

This is also potentially linked to bug 106606 (in this case, the class is not
polymorphic).

Test program (also see on godbolt at: https://godbolt.org/z/PxYGhM8j9)

module t
type :: tree
type(tree), allocatable :: node
end type tree

type :: container

type(tree) :: root

end type container

contains

   type(container) function do_something() result(c)
   allocate(c%root%node)
   allocate(c%root%node%node)
   allocate(c%root%node%node%node)
   end function do_something

end module t


program test_function_output
   use t

   call create_and_finalize()

   contains

  subroutine create_and_finalize()
 type(container) :: c1,c2

 c1 = do_something()
 c2 = c1

 print *, 'allocated? 0 ',allocated(c1%root%node)
 print *, 'allocated? 1 ',allocated(c1%root%node%node)
 print *, 'allocated? 2 ',allocated(c1%root%node%node%node)
  end subroutine create_and_finalize


end program test_function_output

Thanks,
Federico

[Bug libstdc++/107468] New: std::from_chars doesn't always round to nearest

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

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

Bug ID: 107468
   Summary: std::from_chars doesn't always round to nearest
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 
#include 
#include 

int
main()
{
  float f;
  char buf[] = "3.355447e+07";
  fesetround(FE_DOWNWARD);
  auto [ptr, ec] = std::from_chars(buf, buf + sizeof (buf) - 1, f,
std::chars_format::scientific);
  char buf2[128];
  auto [ptr2, ec2] = std::to_chars(buf2, buf2 + 128, f,
std::chars_format::fixed);
  std::cout << std::string_view(buf2, ptr2 - buf2) << std::endl;
}

33554470 isn't representable in IEEE single, only 33554468 and 33554472 are,
the former is 0x1.12p+25 and the latter is 0x1.14p+25 and the latter
has
0 as the least significant digit.  So, round to even should be 33554472 and
that is what happens without the fesetround(FE_DOWNWARD).

When fast_float isn't used, floating_from_chars.cc temporarily overrides the
rounding to nearest, but when it is used, it doesn't.
In most cases it is fine, because fast_float usually computes the mantissa and
exponent in integral code.  But it has two exceptions for this I think.
One is the fast path:
  // Next is Clinger's fast path.
  if (binary_format::min_exponent_fast_path() <= pns.exponent &&
pns.exponent <= binary_format::max_exponent_fast_path() && pns.mantissa
<=binary_format::max_mantissa_fast_p
ath() && !pns.too_many_digits) {
value = T(pns.mantissa);
if (pns.exponent < 0) { value = value /
binary_format::exact_power_of_ten(-pns.exponent); }
else { value = value * binary_format::exact_power_of_ten(pns.exponent);
}
if (pns.negative) { value = -value; }
return answer;
  }
I'm afraid we need to temporarily override rounding to nearest around the
multiplications in there.  And the other one is:
  T b;
  to_float(false, am_b, b);
  adjusted_mantissa theor = to_extended_halfway(b);
where I think we don't really need it but I don't understand the point of
jumping through the floating point format, it encodes am_b into an integer,
memcpys it to float/double (in to_float), then immediately memcpys it back to
an integer (in to_extended called from to_extended_halfway) and then unpacks it
with some adjustments.

[Bug d/107469] New: Build of GDC on FreeBSD 14 fails due to outdated value of __FreeBSD_version

[developer at lorenzosalvadore dot it via Gcc-bugs]

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

Bug ID: 107469
   Summary: Build of GDC on FreeBSD 14 fails due to outdated value
of __FreeBSD_version
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: developer at lorenzosalvadore dot it
  Target Milestone: ---

Build of GDC on FreeBSD 14 (CURRENT) fails. Here is the error message I get

checking command to parse
/wrkdirs/usr/ports/lang/gcc11-devel/work/.build/./gcc/nm output from
/wrkdirs/usr/ports/lang/gcc11-devel/work/.build/./gcc/xgcc
-B/wrkdirs/usr/ports/lang/gcc11-devel
/work/.build/./gcc/ -B/usr/local/x86_64-portbld-freebsd14.0/bin/
-B/usr/local/x86_64-portbld-freebsd14.0/lib/ -isystem
/usr/local/x86_64-portbld-freebsd14.0/include -isystem /usr/local/x86_64
-portbld-freebsd14.0/sys-include -fchecking=1  -m32 object...
/wrkdirs/usr/ports/lang/gcc11-devel/work/gcc-11-20221007/libphobos/libdruntime/core/sys/posix/sys/types.d:201:16:
error: undefine
d identifier '__FreeBSD_version'
  201 | static if (__FreeBSD_version >= 120)
  |^
/wrkdirs/usr/ports/lang/gcc11-devel/work/gcc-11-20221007/libphobos/libdruntime/core/sys/freebsd/config.d:22:6:
error: static assert  "Unsupported version of FreeBSD"
   22 | else static assert(false, "Unsupported version of FreeBSD");
  |  ^
gmake[5]: *** [Makefile:2338: core/runtime.lo] Error 1
gmake[5]: Leaving directory
'/wrkdirs/usr/ports/lang/gcc11-devel/work/.build/x86_64-portbld-freebsd14.0/libphobos/libdruntime'
gmake[4]: *** [Makefile:484: all-recursive] Error 1
gmake[4]: Leaving directory
'/wrkdirs/usr/ports/lang/gcc11-devel/work/.build/x86_64-portbld-freebsd14.0/libphobos'
gmake[3]: *** [Makefile:411: all] Error 2
gmake[3]: Leaving directory
'/wrkdirs/usr/ports/lang/gcc11-devel/work/.build/x86_64-portbld-freebsd14.0/libphobos'
gmake[2]: *** [Makefile:21902: all-target-libphobos] Error 2
gmake[2]: *** Waiting for unfinished jobs

I managed to fix the issue for the FreeBSD ports by updating the values of
__FreeBSD_version in libphobos/libdruntime/core/sys/freebsd/config.d. Please
see the patch in
https://cgit.freebsd.org/ports/diff/lang/gcc11-devel/files/patch-libphobos_libdruntime_core_sys_freebsd_config.d?id=f61fb49b2e76fd4f7a5b7a11510b5109206c19f2
, which introduces a new value for FreeBSD_14 and, while here, updates the
values for the other supported FreeBSD version.

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

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

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

--- Comment #5 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #4)
> __extension__ disables all compatibility warnings.
> 
> This is by design really as headers sometimes needs to be written using C
> code and need to turn off these warnings. 

I don't understand why. If the code is designed only for C (i.e. it will not
work with a C++ compiler), then the C++ compatibility option is not needed to
test the code. Otherwise, the code is buggy, so the compatibility warning is
useful.

[Bug target/107432] __builtin_convertvector generates inefficient code

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

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #8)
> I think we do support FIX_TRUNC_EXPR or FLOAT_EXPR for float <-> int
> conversion of vectors like we now support {CONVERT,NOP}_EXPR for
> just widening/shortening.  At least the GIMPLE verifier allows that.
> 
> The obtabs would be [us]fix and [us]float, not sure if aarch64 makes use
> of those for vector modes or if Richard extended the vectorizer to
> consider those (I only remember int <-> int conversions).
AArch64 doesn't use mixed-size vector fix and float yet, but the hope
is that would in future.  For SVE, the main difficulty is that FP
conversions could raise exceptions, so only the conditional forms
would be interesting for normal predicated loops under default flags.
The unpredicated optabs would require -ffast-math-like flags.

This is probably lower hanging fruit for Advanced SIMD though.

[Bug fortran/107362] Internal compiler error for recursive class

[baradi09 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Bálint Aradi  ---
> I'm getting the same issue on a recursive tree structure, I will post my
> testcase here instead of opening a new bug. 

I am not sure, whether the two bugs are identical. If I understand correctly,
you can compile the code and obtain the segfault during execution. In the case
demonstrated above, the compiler itself generates an ICE during the
compilation, so no executable code is generated at all. (I have changed the
title of the bug report to pronounce that more.)

[Bug c++/107470] New: GCC falsely accepts friend declaration with mismatching requirements

[h2+bugs at fsfe dot org via Gcc-bugs]

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

Bug ID: 107470
   Summary: GCC falsely accepts friend declaration with
mismatching requirements
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

#include 

template 
requires std::unsigned_integral
struct S
{
template  // template 
friend class S;
};

int main()
{
S s;
}


The code is accepted by GCC and rejected by clang. However, if the friend
declaration is fully unconstrained, it is also rejected by GCC.

Code like this exists in libstdc++ which clang stumbles over (I will create a
separate library issue for that).

[Bug libstdc++/107471] New: mismatching constraints in common_iterator

[h2+bugs at fsfe dot org via Gcc-bugs]

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

Bug ID: 107471
   Summary: mismatching constraints in common_iterator
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

In bits/stl_iterator.h:


```cpp
  /// An iterator/sentinel adaptor for representing a non-common range.
  template _Sent>
requires (!same_as<_It, _Sent>) && copyable<_It>
  class common_iterator
  {

// ...

template _Sent2>
friend class common_iterator;
```

The constraints are mismatching. GCC (falsely) accepts this, but clang fails,
see also 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107470

[Bug analyzer/107472] New: Support for the Linux kernel's memory-management APIs

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

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

Bug ID: 107472
   Summary: Support for the Linux kernel's memory-management APIs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Depends on: 106302
Blocks: 106358
  Target Milestone: ---

A suggestion at LPC 2022 was that -fanalyzer could gain knowledge (perhaps via
a plugin) about the behavior of the Linux kernel's memory allocation routines.

See https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html

In particular, note the GPF flags; there seem to be a bunch of contextual rules
about which flags should be set, which perhaps a -fanalyzer plugin could
enforce.  Grokking all these flags seems like another instance of PR 106302.

Plus we ought to do sm-malloc.cc-style checking for leaks, double-free, etc.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
[Bug 106302] RFE: provide a way for -fanalyzer to use target flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug analyzer/106140] RFE: analyzer could complain about misuses of socket APIs

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Depends on||106302
   Last reconfirmed||2022-10-31
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from David Malcolm  ---
I have an implementation of this, but it needs to be able to grok SOCK_DGRAM vs
SOCK_STREAM, which is another instance of PR 106302.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
[Bug 106302] RFE: provide a way for -fanalyzer to use target flags

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

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

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

--- Comment #6 from Vincent Lefèvre  ---
To be clear... I'm not sure about what kind of compatibility warnings one can
get, but it is OK to silence valid extensions, i.e. those that will not give an
error. But invalid extensions, i.e. those that would give an error with a
compat-implied compiler (like in the testcase), should not be silenced by
__extension__.

The problem is that in my original testcase, __extension__ was used in order to
silence the warning for the ({...}) construct, which is still valid with g++.
But as a side effect, it also silences the conversion from the "int *p = q;",
which is invalid in C++ (and is actually *not* an extension as it fails as
shown in my bug report).

[Bug analyzer/107472] Support for the Linux kernel's memory-management APIs

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

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

--- Comment #1 from David Malcolm  ---
(In reply to David Malcolm from comment #0)
> In particular, note the GPF flags
GFP, even

[Bug fortran/107331] Extension and assigning of type results in GNU internal compiler error

[d.mentock at mpie dot de via Gcc-bugs]

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

--- Comment #1 from d.mentock at mpie dot de ---
Created attachment 53802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53802&action=edit
test program that triggers the reported bug with gcc 10.3.0

[Bug c/107473] New: Unexpected warning / error with strncpy

[lli at a10networks dot com via Gcc-bugs]

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

Bug ID: 107473
   Summary: Unexpected warning / error with strncpy
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lli at a10networks dot com
  Target Milestone: ---

When I compile this source code, I hit -Werror=stringop-truncation.

#include 
#include 
#include 

static char a[PATH_MAX];
static char b[PATH_MAX];
void my_test() 
{
snprintf(b, sizeof(b), "/linux/path");
strncpy(a,b,sizeof(a)-1);
}

root:/sources# gcc -Wall -Werror -Wextra -O2 -c test4.c -o test4.o
test4.c: In function 'my_test':
test4.c:10:9: error: 'strncpy' output may be truncated copying 4095 bytes from
a string of length 4095 [-Werror=stringop-truncation]
   10 | strncpy(a,b,sizeof(a)-1);
  | ^~~~
cc1: all warnings being treated as errors

If I compile same file without O2, there is no such issue.

If I add '\0' to the end of a, there is no such issue.

static char a[PATH_MAX];
static char b[PATH_MAX];
void my_test()
{
snprintf(b, sizeof(b), "/linux/path");
strncpy(a,b,sizeof(a)-1);
a[sizeof(a)-1]='\0';
}

If I add memset before strncpy, I hit the issue again.

static char a[PATH_MAX];
static char b[PATH_MAX];
void my_test()
{
snprintf(b, sizeof(b), "/linux/path");
memset(a, 0, sizeof(a));
strncpy(a,b,sizeof(a)-1);
a[sizeof(a)-1]='\0';
}

root:/sources# gcc -Wall -Werror -Wextra -O2 -c test4.c -o test4.o
test4.c: In function 'my_test':
test4.c:11:9: error: 'strncpy' output may be truncated copying 4095 bytes from
a string of length 4095 [-Werror=stringop-truncation]
   11 | strncpy(a,b,sizeof(a)-1);
  | ^~~~
cc1: all warnings being treated as errors

GCC info:
root:/sources# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-host-pie
--enable-host-bind-now --enable-languages=c,c++,fortran,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --without-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_64=x86-64-v2 --with-arch_32=x86-64
--build=x86_64-redhat-linux --with-build-config=bootstrap-lto
--enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20220127 (Red Hat 11.2.1-9) (GCC)

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

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

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

--- Comment #7 from Andrew Pinski  ---
__extension__ is supposed to disable compatibility warnings since they are
written in GNU C. Just happens that you enabled compatibility warnings to C++
which are also disabled.

This is the misunderstanding of what the warning and what __extension__ does.

[Bug ada/107475] New: [10/11/12/13 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32

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

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

Bug ID: 107475
   Summary: [10/11/12/13 Regression] libgnat fails to link
libgnat.so on systems with older glibc on
x86_64-linux-gnux32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

This was introduced with the fix and backports of PR103530 on
x86_64-linux-gnux32 with older glibc versions (checked with 2.31), where dladdr
is still in the libdl.so library, and not included in libc.so as in newer glibc
versions.


[...]
/usr/x86_64-linux-gnux32/bin/ld: s-trasym.o: in function
`system__traceback__symbolic__module_na
me__getXnn':
collect2: error: ld returned 1 exit status
make[8]: *** [gcc-interface/Makefile:677: gnatlib-shared-default] Error 1

https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=9d6c63ba490ec92245f04b5cbafc56abd28e8d22

-- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -2650,13 +2650,18 @@ ifeq ($(strip $(filter-out %x32 linux%,$(target_cpu)
$(target_os))),)
   s-tasinf.adb

[Bug ada/107474] New: [10/11/12/13 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32

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

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

Bug ID: 107474
   Summary: [10/11/12/13 Regression] libgnat fails to link
libgnat.so on systems with older glibc on
x86_64-linux-gnux32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

This was introduced with the fix and backports of PR103530 on
x86_64-linux-gnux32 with older glibc versions (checked with 2.31), where dladdr
is still in the libdl.so library, and not included in libc.so as in newer glibc
versions.


[...]
/usr/x86_64-linux-gnux32/bin/ld: s-trasym.o: in function
`system__traceback__symbolic__module_na
me__getXnn':
collect2: error: ld returned 1 exit status
make[8]: *** [gcc-interface/Makefile:677: gnatlib-shared-default] Error 1

https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=9d6c63ba490ec92245f04b5cbafc56abd28e8d22

-- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -2650,13 +2650,18 @@ ifeq ($(strip $(filter-out %x32 linux%,$(target_cpu)
$(target_os))),)
   s-tasinf.adb

[Bug tree-optimization/105490] unvectorized loop due to bool condition loaded from memory and different size data

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/105464] '-fcompare-debug' failure (length) w/ -Og -fharden-compares -fno-tree-dce

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

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

--- Comment #1 from Andrew Pinski  ---
This is very similar to PR 107183. It looks like reg-stack is causing the
difference too.

[Bug ipa/99670] IPA CP and SRA pass order issue?

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

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

--- Comment #1 from Martin Jambor  ---
I don't think this is a problem with interaction in between the two
passes, IPA-SRA obscures the picture a bit but is not really involved.

The lost opportunity here is that IPA-CP cannot propagate the constant
across the call from foo to bar because we do not have a jump function
that would say that a call argument is a reference to a part of
PARM_DECL and we guarantee that nothing has clobbered what it points
to before the call.

If foo also accepted a pointer to a structure, then our jump functions
can represent that and we can store a compile time constant to k.  In
this case IPA-SRA actually produces a useless parameter but I hope I
have a patch for that.

Cloning bar for all contexts of course means that we do a little bit
of extra work without any benefit (but also without any run-time or
text size cost) but generally I'm afraid that maybe a bit difficult to
detect and fix.

[Bug libstdc++/107471] mismatching constraints in common_iterator

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |11.4
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Looks like this has already been fixed by r13-1769-g3b5567c3ec7e57 which has
been backported as r12-8596 and r11-10165, so IIUC GCC 12.3 and 11.4 (or a
recent enough snapshot of these branches) will contain the fix.

[Bug c++/107470] GCC falsely accepts friend declaration with mismatching requirements

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
dup

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

[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #11 from Patrick Palka  ---
*** Bug 107470 has been marked as a duplicate of this bug. ***

[Bug target/107453] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-31
  Build|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
   Host|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
 CC||ebotcazou at gcc dot gnu.org
 Target|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu   |
 Status|UNCONFIRMED |NEW

--- Comment #2 from Eric Botcazou  ---
Likewise on SPARC64.  It's a TARGET_STRICT_ARGUMENT_NAMING target, so we have
in expand_call:

  /* Count the arguments and set NUM_ACTUALS.  */
  num_actuals =
call_expr_nargs (exp) + num_complex_actuals + structure_value_addr_parm;

  /* Compute number of named args.
 First, do a raw count of the args for INIT_CUMULATIVE_ARGS.  */

  if (type_arg_types != 0)
n_named_args
  = (list_length (type_arg_types)
 /* Count the struct value address, if it is passed as a parm.  */
 + structure_value_addr_parm);
  else
/* If we know nothing, treat all args as named.  */
n_named_args = num_actuals;

which yields n_named_args = num_actuals since type_arg_types == 0 and then:

  if (type_arg_types != 0
  && targetm.calls.strict_argument_naming (args_so_far))
;

so n_named_args = num_actuals in the end and the game is over.

[Bug c/107476] New: Spurious stringop-overflow warning

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

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

Bug ID: 107476
   Summary: Spurious stringop-overflow warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkoning at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53803&action=edit
Reproducer.  Compile with -O3

The attached code produces a stringop-overflow warning complaining that the
code is writing into offset 1 of a one entry array (ttix_buf, reference in
ttix_svc).  In fact it does not, since the index is the control variable in a
for loop that ends on a < one check.

Curiously, if I increase the size of the ttix_buf array, I still see the error
at size 2 or 3, but no complaints at size 4 or above.

[Bug ada/107474] [10/11/12/13 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
.

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

[Bug ada/107475] [10/11/12/13 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
*** Bug 107474 has been marked as a duplicate of this bug. ***

[Bug c/107476] Spurious stringop-overflow warning

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

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

--- Comment #1 from pkoning at gcc dot gnu.org ---
I should mention that I reproduced this (a) on an M1 Mac running gcc (GCC)
13.0.0 20220827 (experimental), and also on an x86 Linux running gcc (GCC)
12.2.0.

[Bug libstdc++/107471] mismatching constraints in common_iterator

[h2+bugs at fsfe dot org via Gcc-bugs]

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

--- Comment #2 from Hannes Hauswedell  ---
Great, thanks!

[Bug c++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine

[littlefox+gcc-bugzilla--- via Gcc-bugs]

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

--- Comment #3 from Mara Sophie Grosch  ---
Standard explicitly allows using unsigned short though:
https://en.cppreference.com/w/cpp/numeric/random/subtract_with_carry_engine

[Bug c++/105550] Missing copy elision with conditional operator

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/96004] Copy elision with conditional

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c/107477] New: spurious -Wrestrict warning

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 107477
   Summary: spurious -Wrestrict warning
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

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

$ gcc -Wrestrict -O1 -c www.c 
In file included from /usr/include/string.h:535,
 from www.c:1:
In function ‘strcpy’,
inlined from ‘foo’ at www.c:11:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:79:10: warning:
‘__builtin_strcpy’ accessing 1 byte at offsets [0, 327680] and [0, 327680]
overlaps 1 byte at offset [0, 327679] [-Wrestrict]


Or:

$ gcc -Wrestrict -m32 -O2 -c www.c 
In file included from /usr/include/string.h:535,
 from www.c:1:
In function ‘strcpy’,
inlined from ‘foo’ at www.c:11:5:
/usr/include/bits/string_fortified.h:79:10: warning: ‘__builtin_strcpy’
accessing 1 byte at offsets [0, 327680] and [0, 327680] overlaps 1 byte at
offset [0, 327679] [-Wrestrict]
   79 |   return __builtin___strcpy_chk (__dest, __src, __glibc_objsize
(__dest)


It doesn't warn with -O2 without -m32.
And if we remove the lines 12,13 of a
test-case, then it never warns with -O2,
whether its -m32 or not.

[Bug tree-optimization/107477] spurious -Wrestrict warning

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

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

--- Comment #1 from Andrew Pinski  ---
Adding:

  if (s < 0) __builtin_unreachable();

"fixes" the warning.

[Bug c/107478] New: ICE compiling for arm-none-eabi during GIMPLE pass: dom

[jwhitakera at gmail dot com via Gcc-bugs]

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

Bug ID: 107478
   Summary: ICE compiling for arm-none-eabi during GIMPLE pass:
dom
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwhitakera at gmail dot com
  Target Milestone: ---

Attempting to compile open source code provided by ST Microelectronics which
resulted in the following crash.

Compiles successfully with: 
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824
(release)

Fails similarly with: 
GNU C11 (Arm GNU Toolchain 11.3.Rel1) version 11.3.1 20220712 (arm-none-eabi)

Reproduction command:

/path/to/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../libexec/gcc/arm-none-eabi/11.3.1/cc1
-fpreprocessed stm32u5xx_hal_dma_ex.i -quiet -mcpu=cortex-m33 -mfpu=fpv5-sp-d16
-mfloat-abi=hard -mthumb -mlibarch=armv8-m.main+dsp+fp
-march=armv8-m.main+dsp+fp -g3 -O2 -Wall -std=gnu11 -version
-ffunction-sections -fdata-sections -o stm32u5xx_hal_dma_ex.s

GNU C11 (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14))
version 11.2.1 20220111 (arm-none-eabi)
compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-44), GMP
version 6.2.1, MPFR version 3.1.6, MPC version 1.0.3, isl version
isl-0.15-1-g835ea3a-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14))
version 11.2.1 20220111 (arm-none-eabi)
compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-44), GMP
version 6.2.1, MPFR version 3.1.6, MPC version 1.0.3, isl version
isl-0.15-1-g835ea3a-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bbcc971fe1d982fd7c3c6bbfd8b1bd3d
during GIMPLE pass: dom
../Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_dma_ex.c: In function
'HAL_DMAEx_List_InsertNode_Head':
../Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_dma_ex.c:1263:19: internal
compiler error: Segmentation fault
0x7f8c9ad2751f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f8c9ad0ed8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f8c9ad0ee3f __libc_start_main_impl
../csu/libc-start.c:392
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/107478] ICE compiling for arm-none-eabi during GIMPLE pass: dom

[jwhitakera at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jacob Abrams  ---
Created attachment 53805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53805&action=edit
preprocessed file

[Bug tree-optimization/107478] ICE compiling for arm-none-eabi during GIMPLE pass: dom

[jwhitakera at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jacob Abrams  ---
I mean to say it similarly reproduces with:

GNU C11 (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14))
version 11.2.1 20220111 (arm-none-eabi)

[Bug tree-optimization/107478] ICE compiling for arm-none-eabi during GIMPLE pass: dom

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.2.1

--- Comment #3 from Andrew Pinski  ---

0x148781c operator_bitwise_not::fold_range(irange&, tree_node*, irange const&,
irange const&) const
???:0
0xe0d0a5 range_fold_unary_expr(int_range<1u>*, tree_code, tree_node*,
int_range<1u> const*, tree_node*)
???:0
0xe74ca1 vr_values::extract_range_from_unary_expr(value_range_equiv*,
tree_code, tree_node*, tree_node*)
???:0
0xe7f5b8 vr_values::extract_range_from_assignment(value_range_equiv*, gassign*)
???:0
0x13ab98e evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
???:0
0xc7d3ab dom_opt_dom_walker::before_dom_children(basic_block_def*)
???:0

[Bug tree-optimization/107478] ICE compiling for arm-none-eabi during GIMPLE pass: dom

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 106878.

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

[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jwhitakera at gmail dot com

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

[Bug tree-optimization/107478] ICE compiling for arm-none-eabi during GIMPLE pass: dom

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

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

--- Comment #5 from Andrew Pinski  ---
The code which is causing the ICE:
pNewNode->LinkRegisters[cllr_offset] = ((uint32_t)pQList->Head & (0x3FFFUL
<< (2U))) | cllr_mask;

[Bug fortran/107331] Extension and assigning of type results in GNU internal compiler error

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed for all gcc version tested (>= 7).

Workaround: replace

  extended_object = generic_object%asExtended()

by

  extended_object = baseType_asExtended (generic_object)

[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gcc-hbfypl at hansdejong dot eu

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

[Bug tree-optimization/105663] [11/12/13 Regression] ICE (segfault) in operator_bitwise_not::fold_range with O1/O2/O3/Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Even though PR 106878 is newer, PR 106878 already has a patch associated with
it for the trunk so closing this one as a dup of bug 106878.

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

[Bug target/107456] std::atomic::fetch_xxx generate LOCK CMPXCHG instead of simpler LOCK instructions

[thiago at kde dot org via Gcc-bugs]

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

Thiago Macieira  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #3 from Thiago Macieira  ---
(In reply to Andrew Pinski from comment #1)
> I was going to say the exact same comment as on LLVM bug report:
> https://github.com/llvm/llvm-project/issues/58685#issuecomment-1295829030
> 
> There is no way atomically fetch and add without xadd.
> 
> There is no "x"and/"x"or  instruction on x86 (note the x here stands for
> exchange rather than exclusive as there is an xor but that is an "exclusive
> or").

With the Remote Atomic Operations (RAO) of AAND, AOR and AXOR, we can do
something.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/71424] std::initializer_list

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug testsuite/105706] [13 regression] gcc.target/powerpc/pr78604.c fails after r13-707-g68e0063397ba82

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/106583] Suboptimal immediate generation on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/105353] __builtin_shufflevector with value dependent constant

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/105431] ICE: SIGSEGV in powi_as_mults_1 (tree-ssa-math-opts.cc:1512) with -Ofast and __builtin_pow()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug target/107479] New: bpf: add __builtin_btf_type_id

[david.faust at oracle dot com via Gcc-bugs]

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

Bug ID: 107479
   Summary: bpf: add __builtin_btf_type_id
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.faust at oracle dot com
  Target Milestone: ---

LLVM supports a BPF builtin:
  __builtin_btf_type_id (param, flag)

which returns the BTF type id of 'param' to the program,
and records a BPF CO-RE relocation according to 'flag'.

We should support the same functionality in GCC. 

These are the relevant changes in LLVM and clang:
  https://reviews.llvm.org/D74572
  https://reviews.llvm.org/D74668

[Bug target/107480] New: bpf: add __builtin_preserve_type_info

[david.faust at oracle dot com via Gcc-bugs]

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

Bug ID: 107480
   Summary: bpf: add __builtin_preserve_type_info
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.faust at oracle dot com
  Target Milestone: ---

LLVM supports a BPF builtin:
  __builtin_preserve_type_info (param, flag)

which is used to generate additional relocations for the
Compile Once - Run Everywhere (CO-RE) mechanism.

This builtin produces a relocation recording the information
about the type of 'param', such as it's size or whether or
not it exists on the host kernel, according to 'flag'. This
information is returned to the program and patched by the
eBPF loader during loading.

We should support this functionality in GCC.

These are the relevant changes in LLVM:
  https://reviews.llvm.org/D83878
  https://reviews.llvm.org/D83242

[Bug target/107481] New: bpf: add __builtin_preserve_enum_value

[david.faust at oracle dot com via Gcc-bugs]

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

Bug ID: 107481
   Summary: bpf: add __builtin_preserve_enum_value
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.faust at oracle dot com
  Target Milestone: ---

LLVM supports a builtin:
  __builtin_preserve_enum_value (param, flag)

which is used to generate additional relocations for the
Compile Once - Run Everywhere (CO-RE) mechanism.

This builtin produces a CO-RE relocation recording information
about the enumerator value in 'param' according to 'flag', and
returns that information to the program. For example, the
integer value of the enumerator, or a boolean value representing
whether or not that enumerator exists on the host kernel. These
values are patched by the eBPF loader according to the CO-RE
relocation.

We should support the same functionality in GCC.

These are the relevant changes in LLVM:
  https://reviews.llvm.org/D83878
  https://reviews.llvm.org/D83242

[Bug c++/105511] [12/13 Regression] Spurious warning: "expected 'template' keyword..." when lt and gt compare over ternary

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I'm not sure if there's anything to fix; the manual says:

In rare cases it is possible to get false positives. To silence this, wrap
the expression in parentheses. For example, the following is treated as a
template, even where m and N are integers:

@smallexample
void NotATemplate (my_class t)
@{
  int N = 5;

  bool test = t.m < N > (0); // Treated as a template.
  test = (t.m < N) > (0); // Same meaning, but not treated as a template.
@}
@end smallexample

so

return ascending ? (a.value < (*b).value) : a.value > (*b).value;

prevents the warning.

[Bug middle-end/107482] New: out-of-bounds heap access in IRA

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

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

Bug ID: 107482
   Summary: out-of-bounds heap access in IRA
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53806&action=edit
_gcov.i

Inside the functions update_costs_from_allocno and
assign_hard_reg the macro ALLOCNO_COLOR_DATA
may be applied to objects of type 'struct ira_allocno' whose
add_data field wasn't changed in the function color_pass to
point to a memory area sized for struct allocno_color_data.

It triggers ASAN and can be reproduced without ASAN with the attached
patch on a compiler built from revision gcc-13-3563-gf36bba013361
for target=microblazeel-linux-gnu:

$ gcc/cc1 -O2 _gcov.i
../../../../gcc/libgcc/libgcov-driver.c: In function ‘gcov_do_dump.constprop’:
../../../../gcc/libgcc/libgcov-driver.c:704:1: internal compiler error: in
assign_hard_reg, at ira-color.cc:2006

[Bug c++/107124] Reference template parameter refers to a temporary object

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug middle-end/107482] out-of-bounds heap access in IRA

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

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

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
Created attachment 53807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53807&action=edit
color-check.patch

[Bug target/90620] Microblaze: ICE similar to bug 16267

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

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

--- Comment #2 from Andrew Pinski  ---

src/proto_htx.c:463:1: error: VOIDmode on an output
 }
 ^
(insn 1768 4216 1773 339 (parallel [
(reg:SI 5 r5 [1471])
(const_int 0 [0])
(mem/v:SI (reg/f:SI 8 r8 [orig:696 _1126 ] [696]) [-1  S4 A32])
(reg:SI 3 r3 [orig:701 _1133 ] [701])
(reg:SI 1469)
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(clobber (scratch:SI))
]) "include/proto/freq_ctr.h":82 85 {atomic_compare_and_swapsi}
 (expr_list:REG_DEAD (reg:SI 1470)
(nil)))
src/proto_htx.c:463:1: internal compiler error: in do_output_reload, at
reload1.c:7978

[Bug target/90620] Microblaze: ICE similar to bug 16267

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-31
   Keywords||ra
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---

  [(match_operand:SI 0 "register_operand" "=&d");; bool output
   (match_operand:SI 1 "register_operand" "=&d");; val output
   (match_operand:SI 2 "nonimmediate_operand" "+Q") ;; memory
   (match_operand:SI 3 "register_operand" "d")  ;; expected value
   (match_operand:SI 4 "register_operand" "d")  ;; desired value
   (match_operand:SI 5 "const_int_operand" "")  ;; is_weak
   (match_operand:SI 6 "const_int_operand" "")  ;; mod_s
   (match_operand:SI 7 "const_int_operand" "")  ;; mod_f
   (clobber (match_scratch:SI 8 "=&d"))]


"d" is:
(define_register_constraint "d" "GR_REGS"
  "A general register.")


So this should work. someone will have to debug this further to see why it is
not.

Can someone please test a newer compiler and if it still happens attach the
preprocessed source?

[Bug rtl-optimization/107482] out-of-bounds heap access in IRA

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

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

 Target|microblazeel-linux-gnu  |microblazeel-linux-gnu,
   ||xtensa-linux-uclibc

--- Comment #2 from jcmvbkbc at gcc dot gnu.org ---
It can also be reproduced with the same input file and command line by the
compiler built from the same revision for target=xtensa-linux-uclibc.

[Bug rtl-optimization/107482] out-of-bounds heap access in IRA

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

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc/2022-October/239794.html

[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions

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

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

--- Comment #10 from Andrew Pinski  ---
>The testcase is a little fragile, it looks like some memory access is not OK.

Looks like it is still not fixed in the end:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604748.html

The patch which hit the problem just added unrelated builtins even.

[Bug c++/106649] [C++23] P2448 - Relaxing some constexpr restrictions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/105423] Bogus -Werror=maybe-uninitialized with definitely initialized variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

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

[vineetg at rivosinc dot com via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||jeffreyalaw at gmail dot com,
   ||vineetg at rivosinc dot com
Summary|riscv: suboptimal codegen   |riscv: suboptimal codegen
   |for shift left, right, left |for
   ||zero_extendsidi2_shifted
   ||w/o bitmanip

--- Comment #3 from Vineet Gupta  ---
Interestingly, if one builds for -march=rv64gc_zbs  # single bit extension

then the optimal code seq for bitmanip is generated, while no zbs instructions
are used.

foo2:
sllia5,a0,32
srlia0,a5,26
ret

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

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Vineet Gupta from comment #3)
> Interestingly, if one builds for -march=rv64gc_zbs  # single bit extension
> 
> then the optimal code seq for bitmanip is generated, while no zbs
> instructions are used.
> 
> foo2:
>   sllia5,a0,32
>   srlia0,a5,26
>   ret

Most likely because
li  a5,1
sllia5,a5,38
Could be done using one instruction.

And then combine could do its thing. But with multiple instructions, it becomes
harder to do.
I have not looked into rtl dumps but this is just knowing what combine can do
and such.

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

[vineetg at rivosinc dot com via Gcc-bugs]

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

--- Comment #5 from Vineet Gupta  ---
Gimple for the test is

  _1 = a_2(D) << 6;
  _3 = _1 & 274877906880;   //  0x3f__ffc0

And 0x3f__ffc0 = 0x40__ - 0x40

For !TARGET_ZBA there's a combiner pattern to match the seq of instruction
generated normally:  define_insn_and_split "zero_extendsidi2_shifted"

Trying 7, 8, 6 -> 9:
7: r78:DI=0x40
8: r77:DI=r78:DI-0x40
  REG_DEAD r78:DI
  REG_EQUAL 0x3fffc0
6: r76:DI=r79:DI<<0x6
  REG_DEAD r79:DI
9: r75:DI=r76:DI&r77:DI
Successfully matched this instruction:
(set (reg:DI 75)
(and:DI (ashift:DI (reg:DI 79)
(const_int 6 [0x6]))
(const_int 274877906880 [0x3fffc0])))


However for !bitmanip, RTL expansion splittable_const_int_operand() breaks up
0x40__ into 1 << 38

(insn 7 6 8 2 (set (reg:DI 78)
  (const_int 1 [0x1])) 

(insn 8 7 9 2 (set (reg:DI 79)
  (ashift:DI (reg:DI 78)
(const_int 38 [0x26]))) 

So we end up with 5 tot insn, which combine can't

And splittable_const_int_operand() has following check

  if (TARGET_64BIT && TARGET_ZBS && SINGLE_BIT_MASK_OPERAND (INTVAL (op)))
return false;

which explains why 

1. zba alone doesn't generate slli.uw
2. zbs generates optimal slli+srli although these have nothing to do with zbs

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

[vineetg at rivosinc dot com via Gcc-bugs]

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

--- Comment #6 from Vineet Gupta  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Vineet Gupta from comment #3)
> > Interestingly, if one builds for -march=rv64gc_zbs  # single bit extension
> > 
> > then the optimal code seq for bitmanip is generated, while no zbs
> > instructions are used.
> > 
> > foo2:
> > sllia5,a0,32
> > srlia0,a5,26
> > ret
> 
> Most likely because
> lia5,1
>   sllia5,a5,38
> Could be done using one instruction.
> 
> And then combine could do its thing. But with multiple instructions, it
> becomes harder to do.
> I have not looked into rtl dumps but this is just knowing what combine can
> do and such.

Looks like our updates collided, indeed that 1 << 38 is the issue here.

[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Sergey Fedorov  ---
(In reply to Iain Sandoe from comment #6)
> it seems to fail "forever" (at least back to 5.5)

Any chance of fixing this before the next update of GCC?

[Bug middle-end/106725] LTO semantics for __attribute__((leaf))

[dthorn at google dot com via Gcc-bugs]

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

--- Comment #6 from Daniel Thornburgh  ---
I spent a little more time on this, and here's a more concrete reproducer of
GCC's current behavior.

The setup again has 3 files: main.c, lto.c, and ext.c. lto.c is a simple
getter-setter interface wrapping a global int. main.c sets the value using this
interface, then makes an __attribute__((leaf)) call to ext.c. This sets the
value to 0. This should be legal, since the call doesn't call back to main.c,
it calls to lto.c.

$ tail -n+1 *.c

==> ext.c <==
void set_value(int v);

void external_call(void) {
  set_value(0);
}

==> lto.c <==
static int value;
void set_value(int v) { value = v; }
int get_value(void) { return value; }

==> main.c <==
#include 

void set_value(int v);
int get_value(void);
__attribute__((leaf)) void external_call(void);

int main(void) {
  set_value(42);
  external_call();
  printf("%d\n", get_value());
}


If we compile main.c and lto.c together using the pre-WHOPR module-merging
flow, the resulting binary assumes that the external call cannot clobber the
value, and it thus prints 42 rather than zero.

$ gcc -c -O2 ext.c
$ gcc -O2 -flto-partition=none main.o lto.o ext.o
$ ./a.out
42

If you instead use WHOPR, it looks like this optimization doesn't trigger:
$ gcc -O2 -flto main.o lto.o ext.o
$ ./a.out
0

At least in the unpartitioned case, it looks like the optimizer is considering
attribute((leaf)) to apply to the whole LTO unit. I'm unsure what WPA's
semantics are, since there may be other reasons why this optimization wasn't
taken there.

[Bug c++/107483] New: c++: fatal error: Killed signal terminated program cc1plus due to out of memory

[seehearfeel at 126 dot com via Gcc-bugs]

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

Bug ID: 107483
   Summary: c++: fatal error: Killed signal terminated program
cc1plus due to out of memory
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seehearfeel at 126 dot com
  Target Milestone: ---

When build llvm used with c++ 13, c++: fatal error: Killed signal terminated
program cc1plus due to out of memory.

https://reviews.llvm.org/D136362#3895385

I can reproduce this issue on x86_64 used with the latest gcc.

(1) Install Fedora36
https://download.fedoraproject.org/pub/fedora/linux/releases/36/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-36-1.5.iso

$ uname -a
Linux fedora 5.17.5-300.fc36.x86_64 #1 SMP PREEMPT Thu Apr 28 15:51:30 UTC 2022
x86_64 x86_64 x86_64 GNU/Linux

(2) Install some packages
sudo yum -y install llvm clang g++ cmake ninja-build bison flex texinfo

$ gcc --version
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)
$ c++ --version
c++ (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)
$ clang --version
clang version 14.0.5 (Fedora 14.0.5-1.fc36)
$ clang++ --version
clang version 14.0.5 (Fedora 14.0.5-1.fc36)

(3) Build llvm

git clone https://github.com/llvm/llvm-project.git
mkdir -p llvm-project/llvm/build
cd llvm-project/llvm/build
cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="X86" \
 -DLLVM_ENABLE_PROJECTS="clang;lldb" \
 -DCMAKE_BUILD_TYPE=Release \
 -DLLVM_BUILD_RUNTIME=OFF
ninja
ninja check-lldb
This is OK used with gcc/c++ 12.

(4) Update gcc to the latest version
git clone git://gcc.gnu.org/git/gcc.git
cd gcc
./contrib/download_prerequisites
mkdir -p build
cd build
../configure --prefix=/usr/local/gcc --enable-checking=release
--enable-languages=c,c++ --disable-multilib
make
sudo make install
export PATH=/usr/local/gcc/bin/:$PATH
export LD_LIBRARY_PATH=/usr/local/gcc/lib64:$LD_LIBRARY_PATH

$ gcc --version
gcc (GCC) 13.0.0 20221029 (experimental)
$ c++ --version
c++ (GCC) 13.0.0 20221029 (experimental)

(5) Do the above (3) again used with gcc/c++ 13

git clone https://github.com/llvm/llvm-project.git
mkdir -p llvm-project/llvm/build
cd llvm-project/llvm/build
cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="X86" \
 -DLLVM_ENABLE_PROJECTS="clang;lldb" \
 -DCMAKE_BUILD_TYPE=Release \
 -DLLVM_BUILD_RUNTIME=OFF \
 -DCMAKE_C_COMPILER="/usr/local/gcc/bin/gcc" \
 -DCMAKE_CXX_COMPILER="/usr/local/gcc/bin/c++"
ninja
ninja check-lldb
We can see that "ninja check-lldb" failed due to OOM
used with gcc/c++ 13.

[Bug c++/107483] c++: fatal error: Killed signal terminated program cc1plus due to out of memory

[seehearfeel at 126 dot com via Gcc-bugs]

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

Tiezhu Yang  changed:

   What|Removed |Added

 CC||seehearfeel at 126 dot com

--- Comment #1 from Tiezhu Yang  ---
dmesg shows that c++ 13 is getting killed by the OOM-killer due to using too
many resources. Adding 64G swap, it is still OOM. c++ 12 has no problem.

[Bug middle-end/106725] LTO semantics for __attribute__((leaf))

[dthorn at google dot com via Gcc-bugs]

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

--- Comment #7 from Daniel Thornburgh  ---
Correction: A compilation line was missed:

+$ gcc -flto -c -O2 main.c lto.c
 $ gcc -c -O2 ext.c

[Bug c++/107483] c++: fatal error: Killed signal terminated program cc1plus due to out of memory

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

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

--- Comment #2 from Andrew Pinski  ---
Which file is it happening?

[Bug c++/107483] c++: fatal error: Killed signal terminated program cc1plus due to out of memory

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

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

--- Comment #3 from Andrew Pinski  ---
Can you attach the preprocessed source of which file gcc is failing out of
memory on?

[Bug c++/107483] c++: fatal error: Killed signal terminated program cc1plus due to out of memory

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

[Bug c++/107483] c++: fatal error: Killed signal terminated program cc1plus due to out of memory

[seehearfeel at 126 dot com via Gcc-bugs]

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

--- Comment #4 from Tiezhu Yang  ---
https://github.com/llvm/llvm-project/blob/main/lldb/unittests/Instruction/RISCV/TestRISCVEmulator.cpp

This issue is introduced in the following commit:

$ git log -p lldb/unittests/Instruction/RISCV/TestRISCVEmulator.cpp
commit 05ae747a5353811f93f5814f24d2335e6229d78a
Author: Emmmer 
Date:   Thu Oct 20 23:05:37 2022 +0800

[LLDB][RISCV] Add RV64C instruction support for EmulateInstructionRISCV


Here is a patch of lldb for optimization, but build also failed used with c++
13.

[LLDB] Optimize lldb build time and memory consumption.
https://reviews.llvm.org/D137041

[Bug c++/107484] New: [13 Regression] ICE: Segmentation fault (in decls_match)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107484
   Summary: [13 Regression] ICE: Segmentation fault (in
decls_match)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++ 13.0.0 20221030 snapshot (g:f36bba013361d8d4f9c7237c3307630de0cc0416) ICEs
when compiling the following testcase, reduced from test/SemaCXX/friend.cpp
from the clang 14 test suite:

namespace qualified_friend_no_match {
  void f(int);
  template void f(T*);
  struct X {
friend void qualified_friend_no_match::f(double);
  };
}

% g++-13 -c ivdlqc5m.cpp
ivdlqc5m.cpp:5:52: internal compiler error: Segmentation fault
5 | friend void qualified_friend_no_match::f(double);
  |^
0x11ef2cf crash_signal
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/toplev.cc:314
0xa1a521 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/tree.h:3531
0xa1a521 decls_match(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/decl.cc:1010
0xa41b64 find_last_decl
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/decl2.cc:1627
0xa41b64 cplus_decl_attributes(tree_node**, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/decl2.cc:1739
0xa29c39 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/decl.cc:14216
0xa4799f grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/decl2.cc:990
0xb3c1ad cp_parser_member_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:27522
0xb07047 cp_parser_member_specification_opt
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:26932
0xb07047 cp_parser_class_specifier
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:26007
0xb07047 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:19383
0xb08fa1 cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:15933
0xb0a1c7 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:15157
0xb3dfa1 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:14970
0xb3d4b9 cp_parser_toplevel_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:14991
0xb3d4b9 cp_parser_declaration_seq_opt
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:14742
0xb3d914 cp_parser_namespace_body
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:21436
0xb3d914 cp_parser_namespace_definition
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:21414
0xb3e2f5 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:14950
0xb3eae9 cp_parser_toplevel_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cp/parser.cc:14991

[Bug rtl-optimization/107482] out-of-bounds heap access in IRA

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

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

--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
The original ASAN report from the unmodified code:

==3761891==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x603000450ef8 at pc 0x01a78e5c bp 0x7ffdcf35f2a0 sp 0x7ffdcf35f298
READ of size 8 at 0x603000450ef8 thread T0
#0 0x1a78e5b in update_costs_from_allocno
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-color.cc:1437
#1 0x1a79983 in update_costs_from_copies
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-color.cc:1524
#2 0x1a7e5fa in assign_hard_reg
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-color.cc:2213
#3 0x1a8e35d in ira_reassign_conflict_allocnos(int)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-color.cc:4052
#4 0x1a260ef in ira /home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira.cc:5834
#5 0x1a27748 in execute /home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira.cc:6084
#6 0x1e9b852 in execute_one_pass(opt_pass*)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2644
#7 0x1e9c335 in execute_pass_list_1
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2753
#8 0x1e9c3b0 in execute_pass_list_1
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2754
#9 0x1e9c454 in execute_pass_list(function*, opt_pass*)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2764
#10 0x1030e5d in cgraph_node::expand()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:1834
#11 0x1032294 in expand_all_functions
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:2008
#12 0x103418c in symbol_table::compile()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:2358
#13 0x1034b20 in symbol_table::finalize_compilation_unit()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:2543
#14 0x23f702b in compile_file
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/toplev.cc:471
#15 0x23ff902 in do_compile
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/toplev.cc:2125
#16 0x240036d in toplev::main(int, char**)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/toplev.cc:2277
#17 0x4823f71 in main /home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/main.cc:39
#18 0x7f1f4e4d4d09 in __libc_start_main ../csu/libc-start.c:308
#19 0x9e4609 in _start
(/home/jcmvbkbc/ws/tensilica/gcc/builds/gcc-13-3563-gf36bba013361-windowed-be/gcc/cc1+0x9e4609)

0x603000450ef8 is located 0 bytes to the right of 24-byte region
[0x603000450ee0,0x603000450ef8)
freed by thread T0 here:
#0 0x7f1f4ec6cb6f in __interceptor_free
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123
#1 0xdf3132 in sbitmap_free(simple_bitmap_def*)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/sbitmap.h:247
#2 0xef31f1 in auto_sbitmap::~auto_sbitmap()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/sbitmap.h:304
#3 0x1aba525 in remove_some_program_points_and_update_live_ranges
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-lives.cc:1586
#4 0x1abad9f in ira_compress_allocno_live_ranges()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-lives.cc:1750
#5 0x1a44483 in ira_flattening(int, int)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-build.cc:3392
#6 0x1a26074 in ira /home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira.cc:5816
#7 0x1a27748 in execute /home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira.cc:6084
#8 0x1e9b852 in execute_one_pass(opt_pass*)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2644
#9 0x1e9c335 in execute_pass_list_1
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2753
#10 0x1e9c3b0 in execute_pass_list_1
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2754
#11 0x1e9c454 in execute_pass_list(function*, opt_pass*)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/passes.cc:2764
#12 0x1030e5d in cgraph_node::expand()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:1834
#13 0x1032294 in expand_all_functions
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:2008
#14 0x103418c in symbol_table::compile()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:2358
#15 0x1034b20 in symbol_table::finalize_compilation_unit()
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/cgraphunit.cc:2543
#16 0x23f702b in compile_file
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/toplev.cc:471
#17 0x23ff902 in do_compile
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/toplev.cc:2125
#18 0x240036d in toplev::main(int, char**)
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/toplev.cc:2277
#19 0x4823f71 in main /home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/main.cc:39
#20 0x7f1f4e4d4d09 in __libc_start_main ../csu/libc-start.c:308

previously allocated by thread T0 here:
#0 0x7f1f4ec6ce8f in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x49fb588 in xmalloc
/home/jcmvbkbc/ws/tensilica/gcc/gcc/libiberty/xmalloc.c:149

SUMMARY: AddressSanitizer: heap-buffer-overflow
/home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/ira-color.cc:1437 in
update_costs_from_allocno
Shadow bytes around the buggy address:
  0x0c0680082180: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
  0x0c0680082190: fd fd fa fa fd 

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

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

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

--- Comment #8 from Vincent Lefèvre  ---
It is bad that __extension__ does two completely different things:
1. Disable warnings associated with GNU extensions, like ({ ... }).
2. Disable compatibility warnings that do not correspond to GNU extensions,
like invalid conversions in C++.

[Bug middle-end/107485] New: gcc-10 ICE with -fnon-call-exception

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

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

Bug ID: 107485
   Summary: gcc-10 ICE with -fnon-call-exception
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spop at gcc dot gnu.org
  Target Milestone: ---

On arm64-linux I see the following crash only on gcc-10.
I do not see the ICE on gcc-11, 12, and trunk. 

$ ~/gcc-10/bld/gcc/cc1plus -fnon-call-exceptions f.ii
[...]
f.ii:29:23: internal compiler error: Segmentation fault
   29 |   template  void x(double *, b, unsigned long *) { f(); }
  |   ^
0x134e58b crash_signal
../../gcc/toplev.c:328
0x1639464 tree_vec_extract(gimple_stmt_iterator*, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/tree-vect-generic.c:140
0x163ca0f expand_vector_condition
../../gcc/tree-vect-generic.c:1044
0x164081f expand_vector_operations_1
../../gcc/tree-vect-generic.c:1988
0x16419f7 expand_vector_operations
../../gcc/tree-vect-generic.c:2240
0x1641b3f execute
../../gcc/tree-vect-generic.c:2284
[...]

$ cat f.ii
typedef long a;
typedef double b;
typedef struct {
  a c __attribute__((__vector_size__(32)));
  b d __attribute__((__vector_size__(32)));
} e;
__attribute__((__always_inline__)) b f() {
  e g, h, i;
  g.c = h.d < i.d;
}
class j {
  bool k();
};
template  void ab(aa, l, n) {
  int o;
  typename n::p q;
  unsigned long r;
  q(0, o, &r);
}
namespace s {
template 
void t(j *, long, long, unsigned long *, int u) {
  n ac;
  void v();
  ab(v, u, ac);
}
} // namespace s
struct w {
  template  void x(double *, b, unsigned long *) { f(); }
  double ad;
  void operator()(double, double, unsigned long *) {
unsigned long m;
x<0>(&ad, 0, &m);
  }
};
using s::t;
struct y {
  using p = w;
};
long ag, ah;
unsigned long ai;
double aj;
bool j::k() {
  using n = y;
  t(this, ag, ah, &ai, aj);
}



git bisect stops on this patch:

commit 1e676cfbe1e13fba2c636b560362ed4f0a56893d
Author: Richard Biener 
Date:   Mon May 18 08:51:23 2020 +0200

middle-end/95171 - inlining of trapping compare into non-call EH fn

This fixes always-inlining across -fnon-call-exception boundaries
for conditions which we do not allow to throw.

2020-05-18  Richard Biener  

PR middle-end/95171
* tree-inline.c (remap_gimple_stmt): Split out trapping compares
when inlining into a non-call EH function.

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

(cherry picked from commit fe168751c5c1c517c7c89c9a1e4e561d66b24663)

[Bug target/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code

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

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

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

https://gcc.gnu.org/g:5c5ef2f9ab545b680cd4bb6c540a9dadb12ead86

commit r13-3586-g5c5ef2f9ab545b680cd4bb6c540a9dadb12ead86
Author: liuhongt 
Date:   Thu Oct 27 18:48:41 2022 +0800

Enable more optimization for 32-bit/64-bit shrd/shld with imm shift count.

This patch doens't handle variable count since it require 5 insns to
be combined to get wanted pattern, but current pass_combine only
supports at most 4.
This patch doesn't handle 16-bit shrd/shld either.

gcc/ChangeLog:

PR target/55583
* config/i386/i386.md (*x86_64_shld_1): Rename to ..
(x86_64_shld_1): .. this.
(*x86_shld_1): Rename to ..
(x86_shld_1): .. this.
(*x86_64_shrd_1): Rename to ..
(x86_64_shrd_1): .. this.
(*x86_shrd_1): Rename to ..
(x86_shrd_1): .. this.
(*x86_64_shld_shrd_1_nozext): New pre_reload splitter.
(*x86_shld_shrd_1_nozext): Ditto.
(*x86_64_shrd_shld_1_nozext): Ditto.
(*x86_shrd_shld_1_nozext): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr55583.c: New test.

[Bug middle-end/107485] gcc-10 ICE with -fnon-call-exception

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

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

--- Comment #1 from Andrew Pinski  ---
Wait is broken on the GCC 10 branch? Or broken just for GCC 10.1.0?

Can you update known to work and known to fail? Because the patch for PR
95171 is on the GCC 10 branch and was only included for GCC 10.3.0.

[Bug middle-end/107485] [10 Regression] gcc-10 ICE with -fnon-call-exception

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|gcc-10 ICE with |[10 Regression] gcc-10 ICE
   |-fnon-call-exception|with -fnon-call-exception
   Last reconfirmed||2022-11-01
   Target Milestone|--- |10.5
  Known to fail||10.3.0
  Known to work||10.2.0
 Status|UNCONFIRMED |NEW
Version|10.0|10.4.1

--- Comment #2 from Andrew Pinski  ---
Never mind, I see 10.2.0 works but 10.3.0 fails.

[Bug middle-end/107485] [10 Regression] gcc-10 ICE with -fnon-call-exception

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
I suspect this is almost the same issue as reported in PR 104450 or very
similar.

The IR in GCC 10 before veclowering:
  _5 = _2 < _3;

   :
  _4 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;

While the IR in GCC 11:
  _4 = _2 < _3;

   :
  _5 = _4;
  _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;

Notice the extra assignment. It is just hiding the issue.

[Bug middle-end/107485] [10 Regression] gcc-10 ICE with -fnon-call-exception

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

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

--- Comment #4 from Andrew Pinski  ---
Yes expand_vector_condition needs a similar fix just as PR 104450 did.

[Bug middle-end/107485] [10 Regression] gcc-10 ICE with -fnon-call-exception

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Yes expand_vector_condition needs a similar fix just as PR 104450 did.

Basically the bug is latent even on the trunk still.


Something like:
diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc
index 350129555a0..f585d3ddbc4 100644
--- a/gcc/tree-vect-generic.cc
+++ b/gcc/tree-vect-generic.cc
@@ -1044,6 +1044,7 @@ expand_vector_condition (gimple_stmt_iterator *gsi,
bitmap dce_ssa_names)
 {
   assign = dyn_cast (SSA_NAME_DEF_STMT (a));
   if (assign != NULL
+ && !stmt_can_throw_internal (cfun, assign)
  && TREE_CODE_CLASS (gimple_assign_rhs_code (assign)) ==
tcc_comparison)
{
  a_is_comparison = true;


Should fix the issue 

[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug analyzer/107486] New: [13 Regression] ICE in deref_rvalue, at analyzer/region-model.cc:3317

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107486
   Summary: [13 Regression] ICE in deref_rvalue, at
analyzer/region-model.cc:3317
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20221030 snapshot (g:f36bba013361d8d4f9c7237c3307630de0cc0416) ICEs
when compiling the following testcase, reduced from
test/CodeGen/2008-07-31-asm-labels.c from the clang 14 test suite, w/
-fanalyzer:

void pipe(int) asm("_thisIsNotAPipe");

void f1(void) {
  pipe(1);
}

% gcc-13 -fanalyzer -c sdgrfguh.c
during IPA pass: analyzer
sdgrfguh.c: In function 'f1':
sdgrfguh.c:4:3: internal compiler error: in deref_rvalue, at
analyzer/region-model.cc:3317
4 |   pipe(1);
  |   ^~~
0x7d4fd0 ana::region_model::deref_rvalue(ana::svalue const*, tree_node*,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/analyzer/region-model.cc:3317
0x13151ea update_model
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/analyzer/region-model-impl-calls.cc:608
0x12d9d4d ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/analyzer/engine.cc:4133
0x12da7aa ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/analyzer/engine.cc:3422
0x12dce9c ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/analyzer/engine.cc:6070
0x12ddeee ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/analyzer/engine.cc:6144
0x12cc848 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/analyzer/analyzer-pass.cc:86

[Bug rtl-optimization/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692

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

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

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

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

commit r13-3587-g4acc4c2be84d66075d60736623c3a7134d129eaa
Author: liuhongt 
Date:   Tue Oct 25 17:10:23 2022 +0800

Fix incorrect digit constraint

Matching constraints are used in these circumstances. More precisely,
the two operands that match must include one input-only operand and
one output-only operand. Moreover, the digit must be a smaller number
than the number of the operand that uses it in the constraint.

In pr107057, the 2 operands in the pattern are both input operands.

gcc/ChangeLog:

PR target/107057
* config/i386/sse.md (*vec_interleave_highv2df): Remove
constraint 1.
(*vec_interleave_lowv2df): Ditto.
(vec_concatv2df): Ditto.
(*avx512f_unpcklpd512): Ditto and renamed to ..
(avx512f_unpcklpd512): .. this.
(avx512f_movddup512): Change to define_insn.
(avx_movddup256): Ditto.
(*avx_unpcklpd256): Remove constraint 1 and renamed
to ..
(avx_unpcklpd256): .. this.
* config/i386/i386.cc (ix86_vec_interleave_v2df_operator_ok):
Disallow MEM_P (op1) && MEM_P (op2).

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107057.c: New test.

[Bug middle-end/107487] New: Issue an error for illegal digit constraint.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 107487
   Summary: Issue an error for illegal digit constraint.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

This is orginally from PR107057, 


(In reply to Hongtao.liu from comment #7)
> And it looks like the pattern is wrongly defined since from [1].
> 
> --cut begin
> Matching constraints are used in these circumstances. More precisely, the
> two operands that match must include one input-only operand and one
> output-only operand. Moreover, the digit must be a smaller number than the
> number of the operand that uses it in the constraint.
> cut end--
> 
> (define_insn "vec_concatv2df"
>   [(set (match_operand:V2DF 0 "register_operand" "=x,x,v,x,v,x,x, v,x,x")
>   (vec_concat:V2DF
> (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,vm,0,0")
> (match_operand:DF 2 "nonimm_or_0_operand"  " x,x,v,1,1,m,m, C,x,m")))]
> 
> 
> For alternatvie 1, the two operands are both input only.
> 
> [1]
> https://gcc.gnu.org/onlinedocs/gccint/Simple-Constraints.html#Simple-
> Constraints


Perhaps an error should be emitted for this situation?

[Bug rtl-optimization/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Hongtao.liu  ---
Fixed in GCC13, and open a separate bug PR107487 for #c9.