[Bug c++/90428] -Wredundant-move could warn for more cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90428 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/106276] Missing -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106276 Marek Polacek changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90428 --- Comment #5 from Marek Polacek --- Ah, this is pretty much a dup of a half of bug 90428.
[Bug c++/90428] -Wredundant-move could warn for more cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90428 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-16 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug middle-end/85620] Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620 --- Comment #12 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:2582080f19e8fe9c1204dfb6fecf744311f00777 commit r13-1717-g2582080f19e8fe9c1204dfb6fecf744311f00777 Author: H.J. Lu Date: Thu Jul 14 10:31:21 2022 -0700 x86: Disable sibcall if indirect_return attribute doesn't match When shadow stack is enabled, function with indirect_return attribute may return via indirect jump. In this case, we need to disable sibcall if caller doesn't have indirect_return attribute and indirect branch tracking is enabled since compiler won't generate ENDBR when calling the caller. gcc/ PR target/85620 * config/i386/i386.cc (ix86_function_ok_for_sibcall): Return false if callee has indirect_return attribute and caller doesn't. gcc/testsuite/ PR target/85620 * gcc.target/i386/pr85620-2.c: Updated. * gcc.target/i386/pr85620-5.c: New test. * gcc.target/i386/pr85620-6.c: Likewise. * gcc.target/i386/pr85620-7.c: Likewise.
[Bug analyzer/106321] New: False positives from -Wanalyzer-tainted-array-index with switch with ranged cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106321
Bug ID: 106321
Summary: False positives from -Wanalyzer-tainted-array-index
with switch with ranged cases
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider: https://godbolt.org/z/o3xE7PozM
static int arr[100];
int __attribute__((tainted_args))
test_5 (int idx)
{
switch (idx)
{
default:
return 0;
case 5 ... 20:
return arr[idx];
/* Extra cases to avoid optimizing the switch away. */
case 22:
return 22;
case 23:
return -17;
}
}
With -fanalyzer -fanalyzer-checker=taint, this falsely complains:
: In function 'test_5':
:11:17: warning: use of attacker-controlled value 'idx' in array lookup
without bounds checking [CWE-129] [-Wanalyzer-tainted-array-index]
11 | return arr[idx];
| ~~~^
'test_5': event 1
|
|4 | test_5 (int idx)
| | ^~
| | |
| | (1) function 'test_5' marked with '__attribute__((tainted_args))'
|
+--> 'test_5': events 2-5
|
|4 | test_5 (int idx)
| | ^~
| | |
| | (2) entry to 'test_5'
|5 | {
|6 | switch (idx)
| | ~~
| | |
| | (3) following 'case 5 ... 20:' branch...
|..
| 10 | case 5 ... 20:
| |
| | |
| | (4) ...to here
| 11 | return arr[idx];
| |
| | |
| | (5) use of attacker-controlled value 'idx'
in array lookup without bounds checking
|
despite the fact that idx has had its bounds checked by dint of being used as
the switch index, and we're now within the ranged case.
Seen on Linux kernel, e.g. in drivers/vfio/pci/vfio_pci_core.c, where
vfio_pci_core_ioctl has:
| 744 | switch (info.index) {
| | ~~ ~~
| | | |
| | | (8) ...to here
| | (9) following ‘case 0 ... 5:’ branch...
|..
| 751 | case VFIO_PCI_BAR0_REGION_INDEX ...
VFIO_PCI_BAR5_REGION_INDEX:
| |
| | |
| | (10) ...to here
and then a false complaint about "use of attacker-controlled value ‘info.index’
in array lookup without upper-bounds checking"
[Bug c++/106294] GCC accepts the undefined behavior operation in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106294 --- Comment #1 from Andrew Pinski --- All compilers I tried (GCC, clang and MSVC) all accept this. There might be a defect report in this area too.
[Bug target/106273] [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?) since r13-1379-ge8a46e5cdab500ea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106273
--- Comment #3 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:fd3d25d6df1cbd385d2834ff3059dfb6905dd75c
commit r13-1716-gfd3d25d6df1cbd385d2834ff3059dfb6905dd75c
Author: Roger Sayle
Date: Fri Jul 15 22:48:56 2022 +0100
PR target/106273: Add earlyclobber to *andn3_doubleword_bmi on x86_64.
This patch resolves PR target/106273 which is a wrong code regression
caused by the recent reorganization to split doubleword operations after
reload on x86. For the failing test case, the constraints on the
andnti3_doubleword_bmi pattern allow reload to allocate the output and
operand in overlapping but non-identical registers, i.e.
(insn 45 44 66 2 (parallel [
(set (reg/v:TI 5 di [orig:96 i ] [96])
(and:TI (not:TI (reg:TI 39 r11 [orig:83 _2 ] [83]))
(reg/v:TI 4 si [orig:100 i ] [100])))
(clobber (reg:CC 17 flags))
]) "pr106273.c":13:5 562 {*andnti3_doubleword_bmi}
where the output is in registers 5 and 6, and the second operand is
registers 4 and 5, which then leads to the incorrect split:
(insn 113 44 114 2 (parallel [
(set (reg:DI 5 di [orig:96 i ] [96])
(and:DI (not:DI (reg:DI 39 r11 [orig:83 _2 ] [83]))
(reg:DI 4 si [orig:100 i ] [100])))
(clobber (reg:CC 17 flags))
]) "pr106273.c":13:5 566 {*andndi_1}
(insn 114 113 66 2 (parallel [
(set (reg:DI 6 bp [ i+8 ])
(and:DI (not:DI (reg:DI 40 r12 [ _2+8 ]))
(reg:DI 5 di [ i+8 ])))
(clobber (reg:CC 17 flags))
]) "pr106273.c":13:5 566 {*andndi_1}
[Notice that reg:DI 5 is set in the first instruction, but assumed
to have its original value in the second]. My first thought was
that this could be fixed by swapping the order of the split instructions
(which works in this case), but in the general case, it's impossible
to handle (set (reg:TI x) (op (reg:TI x+1) (reg:TI x-1)). Hence for
correctness this pattern needs an earlyclobber "=", but we can also
allow cases where the output is the same as one of the operands (using
constraint "0"). The other binary logic operations (AND, IOR, XOR)
are unaffected as they constrain the output to match the first
operand, but BMI's andn is a three-operand instruction which can
lead to the overlapping cases described above.
2022-07-15 Roger Sayle
gcc/ChangeLog
PR target/106273
* config/i386/i386.md (*andn3_doubleword_bmi): Update the
constraints to reflect the output is earlyclobber, unless it is
the same register (pair) as one of the operands.
gcc/testsuite/ChangeLog
PR target/106273
* gcc.target/i386/pr106273.c: New test case.
[Bug c++/106320] New: [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320
Bug ID: 106320
Summary: [10 regression] build failure (due to view requirement
changes?)
Product: gcc
Version: 10.4.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: ---
The following snippet builds on GCC10.3, GCC11.3, GCC12.1 and even MSVC 19.32.
It no longer builds on GCC10.4. This might be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
#include
#include
int main()
{
auto l = std::views::transform([](auto v)
{
auto x = int{}; //!BROKEN - remove this capture and it will work
return v | std::views::transform([x](auto v2)
{
return v2;
});
});
std::vector> v{{5, 6, 7}};
v | l | std::views::join;
}
[Bug jit/106312] jit tests fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106312 --- Comment #6 from Jonathan Wakely --- I still get the same failures.
[Bug jit/106312] jit tests fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106312 --- Comment #5 from Jonathan Wakely --- Ah, I have quite old versions of the prerequisite libs: lrwxrwxrwx. 1 jwakely jwakely 12 Feb 17 2017 gmp -> ./gmp-6.1.0/ lrwxrwxrwx. 1 jwakely jwakely 12 Feb 17 2017 mpc -> ./mpc-1.0.3/ lrwxrwxrwx. 1 jwakely jwakely 13 Feb 17 2017 mpfr -> ./mpfr-3.1.4/ I've removed those symlinks and run contrib/download_prerequisites again and am rebuilding now. If this fixes it, we might need to document that mpfr 3.1.0 is no longer sufficient for GCC: https://gcc.gnu.org/install/prerequisites.html
[Bug jit/106312] jit tests fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106312 --- Comment #4 from Jonathan Wakely --- Valgrind shows: ==29655== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==29655== Bad permissions for mapped region at address 0x64322A8 ==29655==at 0x5D061A4: mpfr_set_emin (in /home/jwakely/build/gcc/libgccjit.so.0.0.1) ==29655==by 0x42A3D27: toplev::main(int, char**) (in /home/jwakely/build/gcc/libgccjit.so.0.0.1) ==29655==by 0x42DEC7B: gcc::jit::recording::context::compile() (in /home/jwakely/build/gcc/libgccjit.so.0.0.1) ==29655==by 0x42C4DDB: gcc_jit_context_compile (in /home/jwakely/build/gcc/libgccjit.so.0.0.1) ==29655==by 0x1000117B: main (in /home/jwakely/build/gcc/testsuite/jit/tut01-hello-world.c.exe)
[Bug jit/106312] jit tests fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106312 --- Comment #3 from Jonathan Wakely --- Created attachment 53304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53304=edit gcc/config.log (gzip compressed)
[Bug jit/106312] jit tests fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106312 --- Comment #2 from Jonathan Wakely --- Created attachment 53303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53303=edit top-level config.log (gzip compressed) Odd, I'm using gcc112 as well. Full configure command is: /home/jwakely/src/gcc/configure --prefix=/home/jwakely/gcc/13 --with-gnu-as --with-gnu-ld --disable-multilib --disable-nls --enable-languages=c,c++,jit --enable-host-shared PATH=/opt/cfarm/git-latest/bin:/opt/cfarm/dejagnu-latest/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/jwakely/.local/bin:/home/jwakely/bin gmp, mpfr and mpc are built in-tree after running ./contrib/download_prerequisites --no-isl
[Bug tree-optimization/106237] [13 regression] serveral tests begin ICEing starting with r13-1575-gcf3a120084e946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106237 --- Comment #4 from seurer at gcc dot gnu.org --- gcc.target/powerpc/pr56605.c was actually reported in PR105267.
[Bug fortran/104313] [10/11/12/13 Regression] ICE verify_gimple failed with -ff2c since r10-2279-ge0af8f52b10385d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104313 --- Comment #9 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:517fb1a78102df43f052c6934c27dd51d786aff7 commit r13-1715-g517fb1a78102df43f052c6934c27dd51d786aff7 Author: Steve Kargl Date: Fri Jul 15 22:07:15 2022 +0200 Fortran: do not generate conflicting results under -ff2c [PR104313] gcc/fortran/ChangeLog: PR fortran/104313 * trans-decl.cc (gfc_generate_return): Do not generate conflicting fake results for functions with no result variable under -ff2c. gcc/testsuite/ChangeLog: PR fortran/104313 * gfortran.dg/pr104313.f: New test.
[Bug jit/106312] jit tests fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106312 --- Comment #1 from David Malcolm --- Seems to work for me (on gcc112); is there a particular machine you tried this on?
[Bug analyzer/106319] New: False positives from -Wanalyzer-va-arg-type-mismatch on int promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106319
Bug ID: 106319
Summary: False positives from -Wanalyzer-va-arg-type-mismatch
on int promotion
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider e.g.:
static void __attribute__((noinline))
__analyzer_consume_n_ints (int num, ...)
{
__builtin_va_list ap;
__builtin_va_start (ap, num);
int i, v;
for (i = 0; i < num; i++)
v = __builtin_va_arg (ap, int);
__builtin_va_end (ap);
}
void test_int (int x)
{
__analyzer_consume_n_ints (1, x);
}
void test_3_ints (int x, int y, int z)
{
__analyzer_consume_n_ints (3, x, y, z);
}
void test_short (short s)
{
__analyzer_consume_n_ints (1, s);
}
Currently we emit this false postive:
../../src/gcc/testsuite/gcc.dg/analyzer/stdarg-types-3.c: In function
‘__analyzer_consume_n_ints’:
../../src/gcc/testsuite/gcc.dg/analyzer/stdarg-types-3.c:9:7: warning: ‘va_arg’
expected ‘int’ but received ‘short int’ for variadic argument 1 of ‘ap’
[CWE-686] [-Wanalyzer-va-arg-type-mismatch]
9 | v = __builtin_va_arg (ap, int);
| ~~^~~~
‘test_short’: events 1-2
|
| 24 | void test_short (short s)
| | ^~
| | |
| | (1) entry to ‘test_short’
| 25 | {
| 26 | __analyzer_consume_n_ints (1, s);
| |
| | |
| | (2) calling ‘__analyzer_consume_n_ints’ from ‘test_short’ with 1
variadic argument
|
+--> ‘__analyzer_consume_n_ints’: events 3-6
|
|2 | __analyzer_consume_n_ints (int num, ...)
| | ^
| | |
| | (3) entry to ‘__analyzer_consume_n_ints’
|..
|8 | for (i = 0; i < num; i++)
| | ~~~
| | |
| | (4) following ‘true’ branch (when ‘i <
num’)...
|9 | v = __builtin_va_arg (ap, int);
| | ~~
| | |
| | (5) ...to here
| | (6) ‘va_arg’ expected ‘int’ but received ‘short int’
for variadic argument 1 of ‘ap’
|
Reproducer: https://godbolt.org/z/6xrvErbov
>From https://en.cppreference.com/w/c/language/variadic :
"At the function call, each argument that is a part of the variable argument
list undergoes special implicit conversions known as default argument
promotions."
From
https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions
:
"In a function call expression when the call is made to
1) a function without a prototype
2) a variadic function, where the argument expression is one of the trailing
arguments that are matched against the ellipsis parameter
Each argument of integer type undergoes integer promotion (see below), and each
argument of type float is implicitly converted to the type double"
>From https://en.cppreference.com/w/c/language/conversion#Integer_promotions :
"Integer promotion is the implicit conversion of a value of any integer type
with rank less or equal to rank of int or of a bit field of type _Bool, int,
signed int, unsigned int, to the value of type int or unsigned int.
If int can represent the entire range of values of the original type (or the
range of values of the original bit field), the value is converted to type int.
Otherwise the value is converted to unsigned int."
Seen on Linux kernel e.g. in drivers/input/keyboard/lm8323.c, where we falsely
complain in lm8323_write_pwm_one about:
418 | lm8323_write(pwm->chip, 4,
with 4 args: int, int, int, u16; the u16 should be promoted to int.
[Bug rtl-optimization/106210] [10/11/12/13 Regression] missing shrink wrap for simple case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Andrew Pinski --- By using the dump file: -fdump-rtl-pro_and_epologue You will see if it was shrink wrapped (which it does in GCC 5.x): Performing shrink-wrapping. While the full dump in GCC 6 has: Attempting shrink-wrapping optimization. Block 2 needs the prologue. Block 4 needs the prologue. After wrapping required blocks, PRO is now 2 Avoiding non-duplicatable blocks, PRO is now 2 Bumping back to anticipatable blocks, PRO is now 2 Here is the part of the dump for GCC 5 which shows the full thing: Attempting shrink-wrapping optimization. insn 6: replaced reg 1 with 0 rescanning insn with uid = 6. Found candidate edge for shrink-wrapping, 2->4. Performing shrink-wrapping. changing bb of uid 60 unscanned insn Duplicating bb 5 to bb 6, 0 active insns. scanning new insn with uid = 64. Removing jump 48.
[Bug ipa/105682] [12/13 Regression] Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function since r10-3542-g0b92cf305dcf3438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > (In reply to Martin Liška from comment #2) > > Started with r10-3542-g0b92cf305dcf3438. > > I think that is when the warning for pure attribute missing started but not > when the warnings for both const and pure attribute started. My bet it is the same issue as PR 105676 really.
[Bug ipa/105682] [12/13 Regression] Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function since r10-3542-g0b92cf305dcf3438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > Started with r10-3542-g0b92cf305dcf3438. I think that is when the warning for pure attribute missing started but not when the warnings for both const and pure attribute started.
[Bug tree-optimization/104276] memset is not elimited when followed by a store loop writing to that memory location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276 --- Comment #8 from Darrell Wright --- What about something like a __builtin_overwrite( ptr, size_t ) that tells the compiler that the range specified will be written. It forms a contract to do so with the compiler and would allow the memset to be eliminated or augmented to part of the range
[Bug fortran/104313] [10/11/12/13 Regression] ICE verify_gimple failed with -ff2c since r10-2279-ge0af8f52b10385d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104313
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> (In reply to Steve Kargl from comment #6)
> > The patch in comment 2 fixes the issue. It was submitted
> > 13 hours after the initial report.
>
> Steve, if you like, I can commit your patch under your name.
> It's pretty obvious.
>
> How about the following testcase?
>
> ! { dg-do compile }
> ! { dg-additional-options "-ff2c -fdump-tree-original" }
> !
> ! PR fortran/104313 - ICE verify_gimple failed with -ff2c
> ! Contributed by G.Steinmetz
>
> function f(a)
> return
> end
>
> ! { dg-final { scan-tree-dump-times "return" 1 "original" } }
LGTM.
Whether my name appears or not isn't important to me. A working compiler is.
The patch itself seems obvious, and I suspect you would have eventually found
it. So commit as yo see fit.
[Bug ada/106318] New: ICE when using 'Range in Ada22 Iterated Component Association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106318
Bug ID: 106318
Summary: ICE when using 'Range in Ada22 Iterated Component
Association
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: cthowie at netzero dot net
Target Milestone: ---
PLATFORM: GCC 12.1.0 toolchain on Windows 10 Intel x64 using MSYS2 (Mingw64).
ISSUE: the use of 'Range sometimes causes an internal compiler error (ICE) when
used in an Iterated Component Association per Ada 2022 syntax. Note that in the
example program below that illustrates the bug, I had to use a nested
subprogram, otherwise 'Range seemed to work OK in the Main subprogram itself:
In short, this syntax works:
new Local_Array'(for I in Arr'First .. Arr'Last =>
but this syntax crashes GNAT:
new Local_Array'(for I in Arr'Range =>
It seems a temporary workaround for the bug is to replace use of 'Range with
'First .. 'Last in cases where GNAT crashes ('Range isn't universally broken).
EXAMPLE PROGRAM DEMONSTRATING THE BUG
=
-- COMPILE WITH: gnatmake main.adb -gnat2022
-- The code as it stands triggers an ICE as indicated in the comment below.
-- The culprit is the "for I in Arr'Range" being used in the Iterated
-- Component Association syntax of Ada 2022.
-- If you comment out the line that "FAILS!", and uncomment the line that
"WORKS",
-- then you'll get stable code using Arr'First .. Arr'Last.
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Unchecked_Deallocation;
procedure Main
is
type Int_Array is array (Positive range <>) of Integer;
type Int_Array_Acc is access Int_Array;
procedure Free is new Ada.Unchecked_Deallocation (Int_Array, Int_Array_Acc);
Foo : constant Int_Array := [1, 2, 3];
procedure Nested -- replaces Arr with a similar one
(Arr : in out Int_Array_Acc)
is
-- +===GNAT BUG ETECTED =
-- | 12.1.0 (x86_64-w64-mingw32) GCC error:
-- | in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:472
Replace : constant Int_Array_Acc :=
--new Int_Array'(for I in Arr'First .. Arr'Last => -- THIS WORKS
new Int_Array'(for I in Arr'Range => -- THIS FAILS!
(if Arr (I) = 2
then 0
else Arr (I)));
begin
Free (Arr);
Arr := Replace;
end Nested;
Goo : Int_Array_Acc := new Int_Array'(Foo);
begin
Put_Line ("Goo =" & Goo.all'Image); -- should print [ 1, 2, 3]
Nested (Goo);
Put_Line ("Goo =" & Goo.all'Image); -- should print [ 1, 0, 3]
Free (Goo);
end Main;
[Bug middle-end/106314] GTY fails on virtual int but not virtual void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314 --- Comment #2 from Aldy Hernandez --- The upcoming floating point ranges (frange) are small enough (one or two words) that I thought we could get away with streaming them as is to GC for global ranges (SSA_NAME_RANGE_INFO). We have a mechanism in place to stream out whatever we want for each range type, so if this is really a problem I can just stream out exactly what I need instead of having the entire frange in GC memory. However, if this is really a problem, perhaps we should fail in gengtype when we see the virtual with some more meaningful parse error?
[Bug middle-end/106314] GTY fails on virtual int but not virtual void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314 --- Comment #1 from Andrew Pinski --- Why do you need these structures to be in GC memory anyways?
[Bug target/105960] [12/13 Regression] Crash in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from H.J. Lu --- Fixed.
[Bug fortran/104313] [10/11/12/13 Regression] ICE verify_gimple failed with -ff2c since r10-2279-ge0af8f52b10385d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104313
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #6)
> The patch in comment 2 fixes the issue. It was submitted
> 13 hours after the initial report.
Steve, if you like, I can commit your patch under your name.
It's pretty obvious.
How about the following testcase?
! { dg-do compile }
! { dg-additional-options "-ff2c -fdump-tree-original" }
!
! PR fortran/104313 - ICE verify_gimple failed with -ff2c
! Contributed by G.Steinmetz
function f(a)
return
end
! { dg-final { scan-tree-dump-times "return" 1 "original" } }
[Bug middle-end/100400] ICE in visit_loops_in_gang_single_region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100400 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #8 from seurer at gcc dot gnu.org --- Any chance we can get r13-262-gda6305558bab9e24943848e4fc5bd8738d7e8f9b backported to gcc 12? kernels-decompose-pr100400-1-2.c still fails there with checks turned on.
[Bug fortran/106317] New: deferred-length character array pointer in derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106317 Bug ID: 106317 Summary: deferred-length character array pointer in derived type Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: clange001 at gmail dot com Target Milestone: --- The following test program gives seg fault with fortran 11.3. I'm trying to store a pointer to a deferred-length character array. The pointer I'd like to store is in a derived type. A regular fortran intrinsic pointer outside of the derived type works fine, but a pointer stored in the derived type does not. My apologies if this has been addressed or reported elsewhere. $ gfortran --version GNU Fortran (MacPorts gcc11 11.3.0_1) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat test.f90 program test type t character(:), pointer, dimension(:) :: a_ptr end type type(t) :: mt character(:), pointer, dimension(:) :: a character(:), pointer, dimension(:) :: b_ptr allocate(character(len=10) :: a(3)) a(:) = '0123456789' print *, a ! this works fine b_ptr => a print *, associated(b_ptr, a) print *, b_ptr ! does not seem work if pointer is member of derived type mt%a_ptr => a print *, associated(mt%a_ptr, a) print *, len(mt%a_ptr) ! string length is NOT correct print *, size(mt%a_ptr) ! array size IS correct print *, mt%a_ptr ! seg fault trying to access print *, 'end' end program test $ gfortran test.f90 $ ./a.out 012345678901234567890123456789 T 012345678901234567890123456789 T 328630909 3 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x10b2f4590 #1 0x10b2f3c1e #2 0x7fff205b5d7c #3 0x10b42d2c5 #4 0x10b430664 #5 0x10b4310bb #6 0x10b2e0cfd #7 0x10b2e0dc6 zsh: segmentation fault ./a.out
[Bug middle-end/105746] vector::resize causes Warray-bounds when optimizer uses __builtin_memcpy or __builtin_memmove since r12-2793-g81d6cdd335ffc60c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105746
Martin Sebor changed:
What|Removed |Added
Component|c++ |middle-end
--- Comment #2 from Martin Sebor ---
The memmove call in the IL the warning is issued for writes past the end of the
allocated block. My guess is that the call to operator new prevents it from
figuring out that the _M_finish initially zeroed out by the vectorized store to
vectp.132_96 is still clear in bb 5. This can be confirmed by replacing the
call to operator new with one to __builtin_malloc() which both eliminates the
warning and also results in much more efficient code(*). There are duplicates
of this problem in Bugzilla. The root cause is probably the fix for pr101480.
[local count: 1073741824]:
vectp.132_96 = [(struct _Vector_impl_data *)v_2(D)]._M_start;
MEM [(union U * *)vectp.132_96] = { 0, 0 };
<<< zero out _M_finish (and _M_start)
MEM[(struct _Vector_impl_data *)v_2(D)]._M_end_of_storage = 0B;
_70 = operator new (100);
[local count: 1073741824]:
__builtin_memset (_70, 255, 100);
_78 = v_2(D)->D.25350._M_impl.D.24657._M_start;<<< zero
if (_78 != 0B)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 439275554]: <<< unreachable
# __cur_127 = PHI <__cur_83(4), _70(3)>
# __first_120 = PHI <__first_82(4), _78(3)>
*__cur_127 ={v} {CLOBBER};
_81 = MEM[(const union U &)__first_120];
MEM[(union U *)__cur_127] = _81;
__first_82 = __first_120 + 1;
__cur_83 = __cur_127 + 1;
goto ; [100.00%]
[local count: 54292484]:
__new_finish_85 = _70 + 100;
_86 = v_2(D)->D.25350._M_impl.D.24657._M_finish; <<< zero
if (_86 != 0B)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 48320311]:<<< unreachable
_93 = (sizetype) _86; <<< zero
__builtin_memmove (__new_finish_85, 0B, _93); <<< warning
...
The IL for the function when operator new is replaced with __builtin_malloc:
struct vector bug ()
{
union U * __new_finish;
union U * __cur;
long unsigned int __n;
union U * _70;
[local count: 1073741824]:
_70 = __builtin_malloc (100);
__builtin_memset (_70, 255, 100);
__new_finish_84 = _70 + 100;
v_2(D)->D.25350._M_impl.D.24657._M_start = _70;
v_2(D)->D.25350._M_impl.D.24657._M_finish = __new_finish_84;
v_2(D)->D.25350._M_impl.D.24657._M_end_of_storage = __new_finish_84;
return v_2(D);
}
[Bug analyzer/106284] False positives from -Wanalyzer-tainted-array-index with optimized conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106284 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed on trunk for gcc 13 by the above patch.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 104477, which changed state. Bug 104477 Summary: [C++23] Implement P2255R2, type trait to detect reference binding to temporary https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104477 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104477 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Implemented in GCC 13.
[Bug middle-end/106316] New: [OpenMP] Auto "declare target" should honor 'declare variant' kind(nohost)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106316
Bug ID: 106316
Summary: [OpenMP] Auto "declare target" should honor 'declare
variant' kind(nohost)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following fails during device lto1 with:
ld: error: undefined symbol: external
>>> referenced by decl-var.c:3
>>> /tmp/cc6C3J6T.o:(onhost)
However, 'external' is never executed on the device.
This seems to be more a 'declare variant' tagging issue than a symbol issue
as it works when keeping only
int onhost(void); /* Only declaration, no definition */
in the second file (and having the definition alongside 'external' in the
first).
→ omp_discover_declare_target_tgt_fn_r, omp_discover_declare_target_fn_r
functions.
First file. Compile with 'gcc -c first.c' --
void external(void)
{
__builtin_printf("Hello World\n");
}
/* See remark:
int onhost(void) { external(); return 5; } */
-
Second file. Compile with 'gcc -fopenmp second.c first.o' --
void external(void);
int onhost(void) { external(); return 5; }
int ondevice(void) { return 7; }
#pragma omp declare variant (onhost) match (device={kind(host)})
#pragma omp declare variant (ondevice) match (device={kind(nohost)})
int stub (void) { return 9; }
#pragma omp declare target
int
caller(void)
{
return stub();
}
#pragma omp end declare target
int
main()
{
__builtin_printf("On host: %d (expected: 5)\n", caller());
#pragma omp target
__builtin_printf("On device: %d (expected: 7)\n", caller());
return 0;
}
-
* * *
A variant would be:
#pragma omp declare variant (ondevice) match (device={kind(nohost)})
int stub (void) { external(); return 9; }
where the 'stub();' is called in the target region but is still unreachable
because of the 'nohost'.
* * *
While some generic solution would be good - i.e. if offload host is only GCN,
it would be nice if the following works - even if it will fail once
-foffload=nvptx is used
#pragma omp declare variant (ondevice) match
(construct={target},device={arch(gcn)})
int stub (void) { external(); return 9; }
handling an explicit 'kind(host)' is very useful.
[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104477
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:9a15d3beace26d68561cb3481b70b0bbcb122ca5
commit r13-1714-g9a15d3beace26d68561cb3481b70b0bbcb122ca5
Author: Marek Polacek
Date: Wed Jun 29 19:00:54 2022 -0400
c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]
This patch implements C++23 P2255R2, which adds two new type traits to
detect reference binding to a temporary. They can be used to detect code
like
std::tuple t("meow");
which is incorrect because it always creates a dangling reference, because
the std::string temporary is created inside the selected constructor of
std::tuple, and not outside it.
There are two new compiler builtins, __reference_constructs_from_temporary
and __reference_converts_from_temporary. The former is used to simulate
direct- and the latter copy-initialization context. But I had a hard time
finding a test where there's actually a difference. Under DR 2267, both
of these are invalid:
struct A { } a;
struct B { explicit B(const A&); };
const B {a};
const B (a);
so I had to peruse [over.match.ref], and eventually realized that the
difference can be seen here:
struct G {
operator int(); // #1
explicit operator int&&(); // #2
};
int&& r1(G{}); // use #2 (no temporary)
int&& r2 = G{}; // use #1 (a temporary is created to be bound to int&&)
The implementation itself was rather straightforward because we already
have the conv_binds_ref_to_prvalue function. The main function here is
ref_xes_from_temporary.
I've changed the return type of ref_conv_binds_directly to tristate,
because
previously the function didn't distinguish between an invalid conversion
and
one that binds to a prvalue. Since it no longer returns a bool, I removed
the _p suffix.
The patch also adds the relevant class and variable templates to
.
PR c++/104477
gcc/c-family/ChangeLog:
* c-common.cc (c_common_reswords): Add
__reference_constructs_from_temporary and
__reference_converts_from_temporary.
* c-common.h (enum rid): Add RID_REF_CONSTRUCTS_FROM_TEMPORARY and
RID_REF_CONVERTS_FROM_TEMPORARY.
gcc/cp/ChangeLog:
* call.cc (ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_directly): ... this. Add a new bool parameter.
Change
the return type to tristate.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
CPTK_REF_CONVERTS_FROM_TEMPORARY.
* cp-tree.h: Include "tristate.h".
(enum cp_trait_kind): Add CPTK_REF_CONSTRUCTS_FROM_TEMPORARY
and CPTK_REF_CONVERTS_FROM_TEMPORARY.
(ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_directly): ... this.
(ref_xes_from_temporary): Declare.
* cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
CPTK_REF_CONVERTS_FROM_TEMPORARY.
* method.cc (ref_xes_from_temporary): New.
* parser.cc (cp_parser_primary_expression): Handle
RID_REF_CONSTRUCTS_FROM_TEMPORARY and
RID_REF_CONVERTS_FROM_TEMPORARY.
(cp_parser_trait_expr): Likewise.
(warn_for_range_copy): Adjust to call ref_conv_binds_directly.
* semantics.cc (trait_expr_value): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
CPTK_REF_CONVERTS_FROM_TEMPORARY.
(finish_trait_expr): Likewise.
libstdc++-v3/ChangeLog:
* include/std/type_traits (reference_constructs_from_temporary,
reference_converts_from_temporary): New class templates.
(reference_constructs_from_temporary_v,
reference_converts_from_temporary_v): New variable templates.
(__cpp_lib_reference_from_temporary): Define for C++23.
* include/std/version (__cpp_lib_reference_from_temporary): Define
for
C++23.
* testsuite/20_util/variable_templates_for_traits.cc: Test
reference_constructs_from_temporary_v and
reference_converts_from_temporary_v.
* testsuite/20_util/reference_from_temporary/value.cc: New test.
* testsuite/20_util/reference_from_temporary/value2.cc: New test.
* testsuite/20_util/reference_from_temporary/version.cc: New test.
gcc/testsuite/ChangeLog:
* g++.dg/ext/reference_constructs_from_temporary1.C: New test.
* g++.dg/ext/reference_converts_from_temporary1.C: New test.
[Bug analyzer/106284] False positives from -Wanalyzer-tainted-array-index with optimized conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106284
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:0a8edfbd37d399d1103d86e134ba0a92f8c873c3
commit r13-1713-g0a8edfbd37d399d1103d86e134ba0a92f8c873c3
Author: David Malcolm
Date: Fri Jul 15 11:28:34 2022 -0400
analyzer: fix taint false positive on optimized range checks [PR106284]
PR analyzer/106284 reports a false positive from
-Wanalyzer-tainted-array-index seen on the Linux kernel
with a version of my patches from:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584372.html
in drivers/usb/class/usblp.c in function âusblp_set_protocolâ handling
usblp_ioctl on IOCNR_SET_PROTOCOL, which has:
| 1337 | if (protocol < USBLP_FIRST_PROTOCOL || protocol >
USBLP_LAST_PROTOCOL)
| |~
| ||
| |(15) following âfalseâ branch...
|..
| 1341 | if (usblp->intf->num_altsetting > 1) {
| |
| || |
| || (16) ...to here
| |(17) following âtrueâ branch...
| 1342 | alts = usblp->protocol[protocol].alt_setting;
| |
| | |
| | (18) ...to here
| | (19) use of attacker-controlled value
âargâ in array lookup without bounds checking
where "arg" is "protocol" (albeit from the caller frame, the ioctl
callback), and is clearly checked at (15).
The root cause is that at -O1 and above fold-const's build_range-check
can optimize range checks
(c>=low) && (c<=high)
into
(c-low>=0) && (c-low<=high-low)
and thus into a single check:
(unsigned)(c - low) <= (unsigned)(high-low).
I initially attempted to fix this by detecting such conditions in
region_model::on_condition, and calling on_condition for both of the
implied conditions. This turned out not to work since the current
sm_context framework doesn't support applying two conditions
simultaneously: it led to a transition from the old state to has_lb,
then a transition from the old state *again* to has_ub, thus leaving
the new state as has_ub, rather than the stop state.
Instead, this patch fixes things by special-casing it within
taint_state_machine::on_condition.
gcc/analyzer/ChangeLog:
PR analyzer/106284
* sm-taint.cc (taint_state_machine::on_condition): Handle range
checks optimized by build_range_check.
gcc/testsuite/ChangeLog:
PR analyzer/106284
* gcc.dg/analyzer/torture/taint-read-index-2.c: New test.
Signed-off-by: David Malcolm
[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303 --- Comment #3 from Roger Sayle --- I think the solution may be similar/related to Richard Biener's fix for PR target/91522.
[Bug c++/94894] avoidable instantiation of conversion function template during overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/106315] New: 7.8% increased codesize on specfp 507.cactuBSSN_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315 Bug ID: 106315 Summary: 7.8% increased codesize on specfp 507.cactuBSSN_r Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: admin at levyhsu dot com Target Milestone: --- when compiled with march_native_ofast_lto (-march=native -Ofast -funroll-loops -flto) on IceLake,CascadeLake, SkylakeW, Zen3 Server/Client, r13-1268-g8c99e307b20c50 results 7.8%-7.9% codesize increment. On aarch64 codesize looks ok.
[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303 --- Comment #2 from Roger Sayle --- Grr... This problem is at (currently just beyond) the limits of my abilities. The TImode STV pass uses data flow to split conversion opportunities up into chains, effectively performing live range splitting, as some of uses/defs of a pseudo register may be in one chain, and other (independent) uses/defs of that pseudo in another chain. In the case reported in the PR, this results in some occurences of (reg 90) being converted to V1TImode, and other occurrences remaining in TImode. Worse, thanks to RTL sharing, calling PUT_MODE on a register in one chain, implicitly affects the mode of that register in other chains/insns. I must admit that I'd assumed that either all instances of a pseudo (like (reg 90)) either get converted or all don't get converted [i.e. chains ~ pseudos]. Fixing this will require either some form of regno mapping or unsharing... (or??). I'll continue investigating, but if anyone can see/knows the correct way to fix this, please do let me know.
[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183 --- Comment #2 from Jonathan Wakely --- (In reply to Ted_lion from comment #1) > The subprocedure of comparison > with old value and waiting for the notification should not be interrupted by > an operation on same atomic object. I'm not sure what you mean here, could you clarify please?
[Bug other/106314] New: GTY fails on virtual int but not virtual void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314
Bug ID: 106314
Summary: GTY fails on virtual int but not virtual void
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: amacleod at redhat dot com
Target Milestone: ---
GTY markers for a struct having virtual int/bool/etc fails, but interestingly
void works:
struct GTY(()) foobar
{
virtual void foo();
virtual int bar();
virtual bool none();
};
build/gengtype \
-S /home/aldyh/src/gcc/gcc -I gtyp-input.list -w
tmp-gtype.state
/home/aldyh/src/gcc/gcc/value-range.h:260: parse error: expected '(', ')',
'GTY', or an identifier, have 'int'
/home/aldyh/src/gcc/gcc/value-range.h:261: parse error: expected '(', ')',
'GTY', or an identifier, have 'bool'
I would prefer not to have to mark trivial structures containing virtuals
manually with GTY((user)).
Any hints from the gengtype experts?
[Bug target/106278] [13 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555 since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106278
--- Comment #3 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:2fd215b03e88baae4e047dcb8dac5daa145dc3b4
commit r13-1707-g2fd215b03e88baae4e047dcb8dac5daa145dc3b4
Author: Roger Sayle
Date: Fri Jul 15 14:39:28 2022 +0100
PR target/106278: Keep REG_EQUAL notes consistent during TImode STV on
x86_64.
This patch resolves PR target/106278 a regression on x86_64 caused by my
recent TImode STV improvements. Now that TImode STV can handle comparisons
such as "(set (regs:CC) (compare:CC (reg:TI) ...))" the convert_insn method
sensibly checks that the mode of the SET_DEST is TImode before setting
it to V1TImode [to avoid V1TImode appearing on the hard reg CC_FLAGS.
Hence the current code looks like:
if (GET_MODE (dst) == TImode)
{
tmp = find_reg_equal_equiv_note (insn);
if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
PUT_MODE (XEXP (tmp, 0), V1TImode);
PUT_MODE (dst, V1TImode);
fix_debug_reg_uses (dst);
}
break;
which checks GET_MODE (dst) before calling PUT_MODE, and when a
change is made updating the REG_EQUAL_NOTE tmp if it exists.
The logical flaw (oversight) is that due to RTL sharing, the destination
of this set may already have been updated to V1TImode, as this chain is
being converted, but we still need to update any REG_EQUAL_NOTE that
still has TImode. Hence the correct code is actually:
if (GET_MODE (dst) == TImode)
{
PUT_MODE (dst, V1TImode);
fix_debug_reg_uses (dst);
}
if (GET_MODE (dst) == V1TImode)
{
tmp = find_reg_equal_equiv_note (insn);
if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
PUT_MODE (XEXP (tmp, 0), V1TImode);
}
break;
While fixing this behavior, I noticed I had some indentation whitespace
issues and some vestigial dead code in this function/method that I've
taken the liberty of cleaning up (as obvious) in this patch.
2022-07-15 Roger Sayle
gcc/ChangeLog
PR target/106278
* config/i386/i386-features.cc
(general_scalar_chain::convert_insn):
Fix indentation whitespace.
(timode_scalar_chain::fix_debug_reg_uses): Likewise.
(timode_scalar_chain::convert_insn): Delete dead code.
Update TImode REG_EQUAL_NOTE even if the SET_DEST is already V1TI.
Fix indentation whitespace.
(convertible_comparison_p): Likewise.
(timode_scalar_to_vector_candidate_p): Likewise.
gcc/testsuite/ChangeLog
* gcc.dg/pr106278.c: New test case.
[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183 Ted_lion changed: What|Removed |Added CC||tedlion_tang at foxmail dot com --- Comment #1 from Ted_lion --- I found my program blocked and it turned out to be the same problem of atomic::wait. According to the C++20 Standard, the function atomic::wait should perform an atomic waiting operations. The subprocedure of comparison with old value and waiting for the notification should not be interrupted by an operation on same atomic object.
[Bug c++/106309] ICE: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106309 --- Comment #5 from Marek Polacek --- Created attachment 53302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53302=edit x.ii.xz Where I got so far.
[Bug c++/106313] GCC incorrectly compiles code involving concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106313 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-07-15 Status|UNCONFIRMED |NEW Keywords||accepts-invalid Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- MSVC accepts this too, although EDG points out that 'obj' is not a constant, and Clang points out that it cannot be evaluated.
[Bug c++/106309] ICE: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106309 Marek Polacek changed: What|Removed |Added Keywords||needs-reduction Status|WAITING |NEW --- Comment #4 from Marek Polacek --- Unfortunately, after 12 hours of reducing, I'm still at 154457 lines :(.
[Bug c++/105946] [12 Regression] ICE in maybe_warn_pass_by_reference, at tree-ssa-uninit.cc:843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105946
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Keywords|needs-reduction |
--- Comment #4 from Martin Liška ---
Reduced to something like:
$ cat ice.ii
void __throw_bad_array_new_length();
template void forward();
template struct __new_allocator {
int allocate(long __n, const void * = 0) {
if (__builtin_expect(__n, false))
if (__n)
__throw_bad_array_new_length();
}
};
template struct allocator_traits;
template struct allocator_traits<__new_allocator<_Tp>> {
using allocator_type = __new_allocator<_Tp>;
using pointer = _Tp;
using size_type = long;
static pointer allocate(allocator_type &__a, size_type __n) {
__a.allocate(__n);
}
};
struct __alloc_traits : allocator_traits<__new_allocator> {};
template
struct _Rb_tree {
struct _Alloc_node {
_Alloc_node(_Rb_tree);
template void operator()(_Arg) {
__new_allocator __trans_tmp_1;
__alloc_traits::allocate(__trans_tmp_1, 1);
}
};
template
int _M_insert_(int, int, _Arg &&, _NodeGen &);
template int _M_insert_unique(_Arg &&);
};
template
template
int _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert_(
int, int, _Arg &&, _NodeGen &__node_gen) {
__node_gen(forward<_Arg>);
}
template
template
int _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert_unique(
_Arg &&) {
int __res_1, __res_0;
_Alloc_node __an(*this);
_M_insert_(__res_0, __res_1, forward<_Arg>, __an);
}
struct set {
_Rb_tree _M_t;
int insert___x;
void insert() { _M_t._M_insert_unique(insert___x); }
};
main() {
set the_set;
the_set.insert();
}
[Bug c++/106313] New: GCC incorrectly compiles code involving concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106313
Bug ID: 106313
Summary: GCC incorrectly compiles code involving concept
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following program is compiled in gcc 12.1 even though it should not as
`obj` is not a constant expression. A working demo can be seen
here:https://godbolt.org/z/aqoMGazfd
```
template
class Person
{
const bool own_pet;
public:
Person() : own_pet(op) {}
consteval bool OwnPet() const { return own_pet; }
consteval bool OwnPetC() const { return true; }
void PatPet() const {}
};
template
concept MustOwnPet = requires(T obj) {
requires obj.OwnPet();
};
void pat(const MustOwnPet auto& p)
{
p.PatPet();
}
template
concept MustOwnPetC = requires(T obj) {
requires obj.OwnPetC();
};
void pat_c(const MustOwnPetC auto& p)
{
p.PatPet();
}
int main()
{
pat_c(Person());
return 0;
}
```
[Bug jit/106312] New: jit tests fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106312
Bug ID: 106312
Summary: jit tests fail on powerpc64le
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu
When built with --disable-multilib --enable-languages=c,c++,jit
--enable-host-shared
make check-gcc gives more than 100 failures like this:
FAIL: tut01-hello-world.c.exe killed: 128208 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: tut01-hello-world.cc.exe killed: 130474 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: tut02-square.c.exe killed: 130611 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: tut02-square.cc.exe killed: 131024 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: tut03-sum-of-squares.c.exe killed: 131625 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: tut03-sum-of-squares.cc.exe killed: 132893 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: toyvm.c.exe killed: 133014 exp8 0 0 CHILDKILLED SIGSEGV {segmentation
violation}
FAIL: toyvm.cc.exe killed: 133290 exp8 0 0 CHILDKILLED SIGSEGV {segmentation
violation}
FAIL: tut05-bf.c.exe killed: 133398 exp8 0 0 CHILDKILLED SIGSEGV {segmentation
violation}
FAIL: emit-alphabet.bf.exe does not have executable bit set
ERROR: ./emit-alphabet.bf.exe does not exist in unix_load.
UNRESOLVED: emit-alphabet.bf.exe execution test
FAIL: test-accessing-bitfield.c.exe killed: 133501 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-error-pr63969-missing-driver.c.exe killed: 134470 exp8 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-register-variable-bad-name.c.exe killed: 134698 exp8 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-register-variable-size-mismatch.c.exe killed: 134973 exp8 0 0
CHILDKILLED SIGSEGV {segmentation violation}
These failures don't occur for the same configuration on x86_64-pc-linux-gnu.
[Bug tree-optimization/104543] [10/11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #14 from Martin Liška --- Btw. started in r12-4526-gd8edfadfc7a9795b.
[Bug fortran/105558] simple 8-bit integer calculation fails with -O3 / march=core-avx2 on some gfortran 8/9/10 versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105558 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #4 from Martin Liška --- Fixed on master with r11-3718-g91ae6930ed4a87d7.
[Bug ipa/105676] [12/13 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105676 Martin Liška changed: What|Removed |Added Summary|[12/13 Regression] Bogus|[12/13 Regression] Bogus |`-Wsuggest-attribute=pure` |`-Wsuggest-attribute=pure` |on function marked |on function marked |`__attribute__((const))`|`__attribute__((const))` ||since ||r12-5437-g09a4ffb72aa2f513 CC||hubicka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Started with r12-5437-g09a4ffb72aa2f513.
[Bug ipa/105682] [12/13 Regression] Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function since r10-3542-g0b92cf305dcf3438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Summary|[12/13 Regression] Both |[12/13 Regression] Both |`-Wsuggest-attribute=pure` |`-Wsuggest-attribute=pure` |and |and |`-Wsuggest-attribute=const` |`-Wsuggest-attribute=const` |on same function|on same function since ||r10-3542-g0b92cf305dcf3438 CC||hubicka at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r10-3542-g0b92cf305dcf3438.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #9 from Jonathan Wakely --- (In reply to frankhb1989 from comment #4) > For CLOCK_REALTIME, the Windows API GetSystemTimeAsFileTime is used. > GetSystemTimePreciseAsFileTime is an improved version which provide "the > highest possible level of precision (<1us)". Unfortunately, the latter is > only available since Windows 8/Windows 2012, which is not suited for > winpthreads for compatibility reason IMO. See this MSDN page for details: > http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895(v=vs.85). > aspx But libstdc++ could call that directly, instead of going through the clock_gettime API.
[Bug ipa/105685] [10/11/12 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Martin Liška --- So on e.g. gcc-9 branch it was fixed with r9-8158-g7bf1518f84d5e6 which is a master backport.
[Bug c++/105746] vector::resize causes Warray-bounds when optimizer uses __builtin_memcpy or __builtin_memmove since r12-2793-g81d6cdd335ffc60c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105746 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|vector::resize |vector::resize |causes Warray-bounds when |causes Warray-bounds when |optimizer uses |optimizer uses |__builtin_memcpy or |__builtin_memcpy or |__builtin_memmove |__builtin_memmove since ||r12-2793-g81d6cdd335ffc60c Last reconfirmed||2022-07-15 Keywords|needs-bisection | --- Comment #1 from Martin Liška --- Started with r12-2793-g81d6cdd335ffc60c.
[Bug target/105960] [12/13 Regression] Crash in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960 --- Comment #11 from Martin Liška --- Can we close it now?
[Bug c/105969] [12 Regression] ICE in Floating point exception since r13-750-g10d1986aee47c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression] ICE in |Floating point exception|Floating point exception ||since ||r13-750-g10d1986aee47c5 Keywords|needs-bisection | --- Comment #4 from Martin Liška --- Btw. started with r13-750-g10d1986aee47c5.
[Bug rtl-optimization/106210] [10/11/12/13 Regression] missing shrink wrap for simple case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Last reconfirmed||2022-07-15 --- Comment #3 from Martin Liška --- @Andrew: Can you please help me how to identify if shrink wrapping happens or not?
[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result since r9-1295-g781ff3d80e88d7d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |spurious -Wunused-value on |spurious -Wunused-value on |a folded frexp, modf, and |a folded frexp, modf, and |remquo calls with unused|remquo calls with unused |result |result since ||r9-1295-g781ff3d80e88d7d0 --- Comment #4 from Martin Liška --- Yes, started with r9-1295-g781ff3d80e88d7d0.
[Bug c++/106309] ICE: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106309 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- (In reply to Martin Liška from comment #2) > It fails for me with the following error: gcc ICEs as reported when invoked like this: % g++-13.0.0 -march=cascadelake -std=c++20 -g -c ccFsUsUT.cc
[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297 --- Comment #4 from Martin Liška --- Created attachment 53301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53301=edit Unreduced test-case
[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297 Martin Liška changed: What|Removed |Added Status|WAITING |NEW CC||marxin at gcc dot gnu.org Summary|stringop-overflow |[12/13 Regression] |misbehaviour on atomic |stringop-overflow ||misbehaviour on atomic ||since ||r12-4725-g88b504b7a8c5affb --- Comment #3 from Martin Liška --- Started with r12-4725-g88b504b7a8c5affb. $ gcc haproxy.i -c -Wno-address-of-packed-member -O2 -Werror haproxy.i: In function ‘run_poll_loop’: haproxy.i:32760:11: error: ‘__atomic_load_8’ writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 32760 | if ((__atomic_load_n(_tgroup_ctx[i].stopping_threads, 0) & ha_tgroup_info[i].threads_enabled) != | ^~ haproxy.i:11985:26: note: at offset 80 into destination object ‘ha_tgroup_ctx’ of size 64 11985 | extern struct tgroup_ctx ha_tgroup_ctx[1]; | ^ cc1: all warnings being treated as errors
[Bug c++/106310] [12/13 Regregression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106310 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[12/13 Regregression] |[12/13 Regregression] |lookup after this-> seems |lookup after this-> seems |wrong for dependent lookup |wrong for dependent lookup ||since ||r12-6754-g30f2c22def739211 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-07-15 Status|UNCONFIRMED |NEW --- Comment #4 from Martin Liška --- Started with r12-6754-g30f2c22def739211.
[Bug c++/106309] ICE: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106309 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|NEW |WAITING --- Comment #2 from Martin Liška --- It fails for me with the following error: In file included from /opt/feen_rsync/lib/feen/fe/fe.h:22, from /opt/feen_rsync/lib/feen/fe/test/h1_hierarchic_fe_space_tests.cc:9: /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h: In instantiation of ‘feen::fe::H1HierarchicFeSpace::fe_t<0> feen::fe::H1HierarchicFeSpace::Restrict(ENTITY&&) const [with ENTITY = feen::mesh::single_ref_el_hanging::Cell&; fe_t<0> = feen::fe::H1HierarchicFiniteElement]’: /opt/feen_rsync/lib/feen/fe/test/h1_hierarchic_fe_space_tests.cc:103:34: required from here /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:66:12: error: class template argument deduction failed: /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:66:12: error: no matching function for call to ‘H1HierarchicFiniteElement(feen::mesh::single_ref_el_hanging::Cell&)’ /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:23:3: note: candidate: ‘template H1HierarchicFiniteElement(ENTITY2&&)-> feen::fe::H1HierarchicFiniteElement’ /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:23:3: note: template argument deduction/substitution failed: /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:66:12: note: couldn’t deduce template parameter ‘ENTITY’ /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:19:7: note: candidate: ‘template H1HierarchicFiniteElement(feen::fe::H1HierarchicFiniteElement)-> feen::fe::H1HierarchicFiniteElement’ /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:19:7: note: template argument deduction/substitution failed: /opt/feen_rsync/lib/feen/fe/h1_hierarchic_fe_space.h:66:12: note: ‘feen::mesh::single_ref_el_hanging::Cell’ is not derived from ‘feen::fe::H1HierarchicFiniteElement’
[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-07-15 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|[13 Regression] ICE on |[13 Regression] ICE on |valid code at -O3 with |valid code at -O3 with |-fno-inline-small-functions |-fno-inline-small-functions |on x86_64-linux-gnu: in |on x86_64-linux-gnu: in |extract_insn, at|extract_insn, at |recog.cc:2791 |recog.cc:2791 since ||r13-1607-gc3ed9e0d6e96d869 --- Comment #1 from Martin Liška --- Started with r13-1607-gc3ed9e0d6e96d869.
[Bug c++/84695] Missed opportunity to issue warning about override [-Winconsistent-missing-override]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84695 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #3 from David Binderman --- Interestingly, gcc trunk source code produces this warning when compiled by clang: $ fgrep Winco /tmp/0 | sort | uniq -c 1 ../../trunk.git/gcc/analyzer/region-model.cc:3007:8: warning: 'visit_unaryop_svalue' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] 1 ../../trunk.git/gcc/analyzer/region-model.cc:3031:8: warning: 'visit_repeated_svalue' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] 2 ../../trunk.git/gcc/config/i386/i386-features.h:184:8: warning: 'convert_op' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] 2 ../../trunk.git/gcc/config/i386/i386-features.h:199:8: warning: 'convert_op' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] 11 ../../trunk.git/gcc/value-range-equiv.h:57:8: warning: 'set_undefined' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] 11 ../../trunk.git/gcc/value-range-equiv.h:58:8: warning: 'set_varying' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] 11 ../../trunk.git/gcc/value-range-equiv.h:68:8: warning: 'dump' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] $ A couple in the analyzer, a couple in the i386 machine specific code and 3 in value-range-equiv.h. Might be worth fixing ?
