[Bug tree-optimization/104406] SLP discovery doesn't use TWO_OPERAND nodes as seeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104406 --- Comment #1 from Andrew Pinski --- Almost positive this is a dup of bug 31485
[Bug debug/104407] New: [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407
Bug ID: 104407
Summary: [10/11/12 Regression] '-fcompare-debug' failure
(length) w/ -std=c++17 -O1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc 12.0.1 20220130 snapshot (g:baf98320ac6cd56da0c0b460fb94e3b87a79220d) fails
-fcompare-debug check when compiling the following testcase, extracted from
gcc/testsuite/g++.dg/cpp1z/decomp13.C, w/ -O1:
struct A { int i; long j; int k : 2; char l; } a;
auto [ aa, bb, cc, dd ] = a;
namespace N
{
auto & [ m, n, o, ppp ] = a;
}
% x86_64-unknown-linux-gnu-g++-12.0.1 -O1 -fcompare-debug -c t3pwb1uu.C
x86_64-unknown-linux-gnu-g++-12.0.1: error: t3pwb1uu.C: '-fcompare-debug'
failure (length)
--- t3pwb1uu.C.gkd 2022-02-06 14:31:15.936434434 +0700
+++ t3pwb1uu.gk.C.gkd 2022-02-06 14:31:15.996430437 +0700
@@ -11,7 +11,7 @@
(note # 0 0 NOTE_INSN_FUNCTION_BEG)
(note # 0 0 NOTE_INSN_DELETED)
(insn # 0 0 2 (set (reg:TI 20 xmm0 [89])
-(mem/c:TI (symbol_ref:DI ("a") [flags 0x2] ) [ a+0 S16
A128])) "t3pwb1uu.C":3:6# {*movti_internal}
+(mem/c:TI (symbol_ref:DI ("a") [flags 0x2] ) [ a+0 S16
A64])) "t3pwb1uu.C":3:6# {*movti_internal}
(nil))
(insn # 0 0 2 (set (mem/c:TI (symbol_ref:DI ("_ZDC2aa2bb2cc2ddE") [flags 0x2]
) [ D.+0 S16 A128])
(reg:TI 20 xmm0 [89])) "t3pwb1uu.C":3:6# {*movti_internal}
@@ -19,9 +19,9 @@
(nil)))
(insn # 0 0 2 (set (reg:DI 0 ax [orig:87 a+16 ] [87])
(mem/c:DI (const:DI (plus:DI (symbol_ref:DI ("a") [flags 0x2]
)
-(const_int 16 [0x10]))) [ a+16 S8 A128]))
"t3pwb1uu.C":3:6# {*movdi_internal}
+(const_int 16 [0x10]))) [ a+16 S8 A64])) "t3pwb1uu.C":3:6#
{*movdi_internal}
(expr_list:REG_EQUIV (mem/c:DI (const:DI (plus:DI (symbol_ref:DI ("a")
[flags 0x2] )
-(const_int 16 [0x10]))) [ a+16 S8 A128])
+(const_int 16 [0x10]))) [ a+16 S8 A64])
(nil)))
(insn # 0 0 2 (set (mem/c:DI (const:DI (plus:DI (symbol_ref:DI
("_ZDC2aa2bb2cc2ddE") [flags 0x2] )
(const_int 16 [0x10]))) [ D.+16 S8 A128])
[Bug middle-end/104405] Inefficient register allocation on complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405 --- Comment #1 from Andrew Pinski --- I am almost positive there are duplicates of this bug already. It is similar to the struct argument passing one too.
[Bug tree-optimization/104406] New: SLP discovery doesn't use TWO_OPERAND nodes as seeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104406
Bug ID: 104406
Summary: SLP discovery doesn't use TWO_OPERAND nodes as seeds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
the following example
#include
complex double f (complex double a, complex double b)
{
return a * b;
}
compiled at -Ofast fails to SLP because at tree level it generates
a$real_5 = REALPART_EXPR ;
a$imag_6 = IMAGPART_EXPR ;
b$real_7 = REALPART_EXPR ;
b$imag_8 = IMAGPART_EXPR ;
_9 = a$real_5 * b$real_7;
_10 = a$imag_6 * b$imag_8;
_11 = a$real_5 * b$imag_8;
_12 = a$imag_6 * b$real_7;
_13 = _9 - _10;
_14 = _11 + _12;
_3 = COMPLEX_EXPR <_13, _14>;
But SLP discovery does not attempt to start at _13 and _14, instead starts at
the multiplies:
note: Starting SLP discovery for
note: _11 = a$real_5 * b$imag_8;
note: _12 = a$imag_6 * b$real_7;
And ultimately fails because it doesn't know what to do with REALPART_EXPR and
IMAGPART_EXPR.
[Bug c/104405] New: Inefficient register allocation on complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405
Bug ID: 104405
Summary: Inefficient register allocation on complex arithmetic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The following testcase
#include
complex double f (complex double a, complex double b)
{
return a * b * I;
}
compiled at -Ofast has unneeded copies of input
i.e.
f:
fmovd4, d1
fmovd1, d0
fmuld0, d4, d2
fmuld4, d4, d3
fnmadd d0, d1, d3, d0
fnmsub d1, d1, d2, d4
ret
the first two moves are unneeded and looks to be an artifact of how
IMAGPART_EXPR and REALPART_EXPR are expanded. This seems to be a generic issue
as both x86 and Arm targets seem to have the same problem.
[Bug fortran/104404] New: Incorrect CFI_cdesc_t "type" member for assumed-type, assumed-rank complex dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104404
Bug ID: 104404
Summary: Incorrect CFI_cdesc_t "type" member for assumed-type,
assumed-rank complex dummy arguments
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at archaeologic dot codes
Target Milestone: ---
For an assumed-type, assumed-rank complex dummy argument in a C interface,
gfortran 11.2.0 passes a CFI_cdesc_t object with a "type" member that does not
match the corresponding CFI_type_float_Complex and CFI_type_double_Complex
values. Ian the case of a complex(c_float_complex) argument, passed "type"
member corresponds to CFI_type_double_Complex. For a complex(c_double_complex)
argument, the "type" member has a value that I don't recognize. Does anyone
know whether this has been fixed on the 12 branch?
% cat c_descriptor.c
#include
#include
void c_descriptor(CFI_cdesc_t* c)
{
printf("a_desc->type = %d \n", c->type);
printf("a_desc->elem_len = %d \n", c->elem_len);
printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
}
% cat c_descriptor.c
#include
#include
void c_descriptor(CFI_cdesc_t* c)
{
printf("a_desc->type = %d \n", c->type);
printf("a_desc->elem_len = %d \n", c->elem_len);
printf("CFI_type_float_Complex = %d \n", CFI_type_float_Complex);
printf("CFI_type_double_Complex = %d \n", CFI_type_double_Complex);
}
(base) rouson@CLaSS adhoc % cat assumed-type.f90
module c_descriptor_m
implicit none
contains
module subroutine print_type_info(a)
type(*), intent(inout), contiguous, target :: a(..)
interface
subroutine c_descriptor(a) bind(C)
implicit none
type(*) a(..)
end subroutine
end interface
call c_descriptor(a)
end subroutine
end module
use c_descriptor_m
use iso_c_binding
implicit none
complex(c_float_complex) :: z_float = (0._c_float, 0._c_float)
complex(c_double_complex):: z_double = (0._c_double, 0._c_double)
print*, "- complex(c_float_complex) "
call print_type_info(z_float)
print*, "- complex(c_double_complex) ---"
call print_type_info(z_double)
end
% gfortran c_descriptor.c assumed-type.f90
% ./a.out
- complex(c_float_complex)
a_desc->type = 2052
a_desc->elem_len = 8
CFI_type_float_Complex = 1028
CFI_type_double_Complex = 2052
- complex(c_double_complex) ---
a_desc->type = 4100
a_desc->elem_len = 16
CFI_type_float_Complex = 1028
CFI_type_double_Complex = 2052
% gfortran --version
GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0
[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104402 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- Created attachment 52358 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52358=edit Patch which I am going to test Not the best patch but solves the issue. I will clean it up later tonight.
[Bug c++/104398] [c++20] ICE triggered by templated class with base class containing `using enum`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104398 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-02-06 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103081 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
Feng Xue changed:
What|Removed |Added
CC||fxue at os dot
amperecomputing.com
--- Comment #7 from Feng Xue ---
(In reply to Jakub Jelinek from comment #6)
> It is in
> /* Recursively generate lattice values with a limited count. */
> FOR_EACH_VEC_ELT (val_seeds, i, src_val)
> {
> for (int j = 1; j < max_recursive_depth; j++)
> {
> tree cstval = get_val_across_arith_op (opcode, opnd1_type,
> opnd2,
> src_val, res_type);
> if (!cstval
> || !ipacp_value_safe_for_type (res_type, cstval))
> break;
>
> ret |= dest_lat->add_value (cstval, cs, src_val, src_idx,
> src_offset, _val, j);
> gcc_checking_assert (src_val);
> }
> }
> (but there is another spot doing the similar thing) where it would be nice
> to also break if cstval is non-NULL and safe for type, but is outside of the
> value range. I have no idea how to get from this spot at that value range
> though.
By default, ipcp is told to clone a recursive function 8 times, that exceeds
value space of index in this case. We could rely on ipa fnsummary on condition
predicate of a call to avoid generating never-executed copy. I will take it.
[Bug target/104401] [x86] Failure to recognize min/max pattern using pcmp+pblendv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104401 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-05 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- (set (reg:V16QI 93) (unspec:V16QI [ (subreg:V16QI (reg/v:V2DI 92 [ input ]) 0) (subreg:V16QI (reg/v:V2DI 91 [ value ]) 0) (subreg:V16QI (gt:V4SI (subreg:V4SI (reg/v:V2DI 92 [ input ]) 0) (subreg:V4SI (reg/v:V2DI 91 [ value ]) 0)) 0) ] UNSPEC_BLENDV)) blend uses unspec which makes this a little harder
[Bug target/104401] [x86] Failure to recognize min/max pattern using pcmp+pblendv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104401 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104402
Andrew Pinski changed:
What|Removed |Added
Known to work||8.1.0
Last reconfirmed||2022-02-05
Target Milestone|--- |9.5
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Known to fail||9.1.0
Summary|ICE on valid code: in |[9/10/11/12 Regression] ICE
|do_jump_1, at dojump.c |on valid code caused by not
||lowering complex int
||compare inside a COND_EXPR
--- Comment #1 from Andrew Pinski ---
Confirmed.
The problem is obvious complex lowering does not handle COND_EXPR.
In GCC 8.x we had:
_4 = a.1_3 != __complex__ (0, 0);
_6 = _4 ? 3 : 2;
While in GCC 9+ we have:
_5 = a.1_3 != __complex__ (0, 0) ? 3 : 2;
Complex lowering didn't lower the 9+ IR.
Also here is a better testcase:
_Complex int a;
char b;
int main() {}
void c() {
if (b != 2 + (long)(a != 0 ^ 0))
__builtin_abort();
}
[Bug c++/104403] [12 Regression] ICE while optimizing lambda that returns address of a static variable hidden in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104403 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-02-05 Target Milestone|--- |12.0 Priority|P3 |P1 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Summary|ICE while optimizing lambda |[12 Regression] ICE while |that returns address of a |optimizing lambda that |static variable hidden in a |returns address of a static |switch |variable hidden in a switch Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r12-4206-g8892d532d66910e518bc135a851a104322385ca2
[Bug c++/104358] Assignable template lambda as function parameter is incorrectly reduced to type of "int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104358
--- Comment #2 from qingzhe huang ---
Here are more tests (https://www.godbolt.org/z/5qc8jTGa8) to show that only
msvc is giving the correct result.
It just illustrates the use cases of this definition and why it should be
allowed.
1. By using operator "+", here the type "Lambda" is just a free function
pointer.
template
using Lambda=decltype(+[](T){});
static_assert(is_same_v, void(*)(int)>);
2. The "foo" takes "Lambda" as parameter
template
T foo(T&&, Lambda);
3. As "Lambda" is just a function pointer, "foo" should allow both free
function pointer or lambda(by conversion operator) to be used as argument. And
because GCC mistakenly consider "foo" signature as "int(*)(int&&,
/*Lambda*/int)", this is not possible.
static_assert(is_same_v), int(*)(int&&, int)>);
These are use cases for "foo":
a) using lambda directly
foo(5, [](int n){});// lambda conversion operator!
b) using converted function pointer from lambda by operator "+"
auto funptr=+[](int n){};
foo(5, funptr);
c) directly using a function pointer
void(*ptr)(int)=funptr;
foo(5, ptr);
[Bug c++/104403] New: ICE while optimizing lambda that returns address of a static variable hidden in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104403
Bug ID: 104403
Summary: ICE while optimizing lambda that returns address of a
static variable hidden in a switch
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: franwade33 at googlemail dot com
Target Milestone: ---
On gcc 12.0.1, the following gives an internal compiler error:
// g++-12 -std=c++17 -O1
// g++-12 -std=c++20 -O1
int main() {
[]{
switch (0) {
case 0:
static int value;
return
}
};
}
Reproduced here: https://godbolt.org/z/5PKGjGo33
This is the compiler output:
: In static member function 'static constexpr int*
main()_FUN()':
:8:5: in 'constexpr' expansion of '0->main()::()'
:8:5: internal compiler error: in cxx_eval_constant_expression,
at cp/constexpr.cc:6652
8 | };
| ^
0x2169b09 internal_error(char const*, ...)
???:0
0x73cd21 fancy_abort(char const*, int, char const*)
???:0
0x7bc242 maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0x87d5db fold_for_warn(tree_node*)
???:0
0xa9048e check_return_expr(tree_node*, bool*)
???:0
0xa19a9e finish_return_stmt(tree_node*)
???:0
0x8997f3 maybe_add_lambda_conv_op(tree_node*)
???:0
0x97f7ed c_parse_file()
???:0
0xb0f1c2 c_common_parse_file()
???:0
It compiles fine on gcc 11.2.0, and it also compiles fine with -std=c++2b (and
-std=c++14, where a closure type's operator() can't be implicitly constexpr).
Probably has something to do with C++2b P2242R3 allowing static variables in
constexpr functions.
[Bug c/104402] New: ICE on valid code: in do_jump_1, at dojump.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104402
Bug ID: 104402
Summary: ICE on valid code: in do_jump_1, at dojump.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: k.even-mendoza at imperial dot ac.uk
Target Milestone: ---
ICE started from gcc-9 and still appears in gcc-12 (I tested it with gcc (GCC)
12.0.0 20220116 (experimental)) with this code and -O2:
#include
_Complex a;
char b;
void main() {}
void c() {
if (b != 2 + (long)(a != 0 ^ 0))
abort();
}
dump this:
/home/user42/data/gcc-csmith-1201/gcc-install/bin/gcc -O2 fuzzer-file-37731.c
==
during RTL pass: expand
fuzzer-file-37731.c: In function ‘c’:
fuzzer-file-37731.c:5:6: internal compiler error: in do_jump_1, at dojump.c:207
5 | void c() {
| ^
0x6e6d97 do_jump_1
.././../gcc-source/gcc/dojump.c:207
0xb49847 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
.././../gcc-source/gcc/expr.c:10242
0xb4f24f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
.././../gcc-source/gcc/expr.c:10502
0xa9b916 expand_normal
.././../gcc-source/gcc/expr.h:307
0xa9b916 do_compare_and_jump
.././../gcc-source/gcc/dojump.c:1257
0xa9d929 do_jump_1
.././../gcc-source/gcc/dojump.c:219
0xa238e0 expand_gimple_cond
.././../gcc-source/gcc/cfgexpand.c:2645
0xa240fc expand_gimple_basic_block
.././../gcc-source/gcc/cfgexpand.c:5928
0xa25ce7 execute
.././../gcc-source/gcc/cfgexpand.c:6795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/104401] New: [x86] Failure to recognize min/max pattern using pcmp+pblendv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104401
Bug ID: 104401
Summary: [x86] Failure to recognize min/max pattern using
pcmp+pblendv
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
__m128i min32(__m128i value, __m128i input)
{
return _mm_blendv_epi8(input, value, _mm_cmplt_epi32(value, input));
}
With -O3 -msse4.1, GCC outputs this:
min32(long long __vector(2), long long __vector(2)):
movdqa xmm2, xmm0
movdqa xmm0, xmm1
movdqa xmm3, xmm1
pcmpgtd xmm0, xmm2
pblendvb xmm3, xmm2, xmm0
movdqa xmm0, xmm3
ret
LLVM instead outputs this:
min32(long long __vector(2), long long __vector(2)):
pminsd xmm0, xmm1
ret
The equivalent code with cmpgt used instead of cmplt can be optimized to
pmaxsd.
[Bug c/104399] Mingw to generate bogus.o on French locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104399 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-05 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you add -save-temps and look at the generated .s file. If they are the same you should report this to binutils.
[Bug rtl-optimization/104400] New: [12 Regression] v850e lra/reload failure after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
Bug ID: 104400
Summary: [12 Regression] v850e lra/reload failure after recent
change
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
After this change:
commit 85419ac59724b7ce710ebb4acf03dbd747edeea3 (HEAD, refs/bisect/bad)
Author: Vladimir N. Makarov
Date: Fri Jan 21 13:34:32 2022 -0500
[PR103676] LRA: Calculate and exclude some start hard registers for reload
pseudos
LRA and old reload pass uses only one register class for reload pseudos
even if
operand constraints contain more one register class. Let us consider
constraint 'lh' for thumb arm which means low and high thumb registers.
Reload pseudo for such constraint will have general reg class (union of
low and high reg classes). Assigning the last low register to the reload
pseudo is wrong if the pseudo is of DImode as it requires two hard regs.
But it is considered OK if we use general reg class. The following patch
solves this problem for LRA.
gcc/ChangeLog:
PR target/103676
[ ... ]
The v850e-elf port will no longer build newlib due to a spill failure.
I've narrowed the test down, but haven't done any debugging to see if this is
really an LRA issue or a backend issue.
Compile with -O2 -mv850e3v5 to trigger:
./cc1 -O2 -mv850e3v5 j.c
frob
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1200k} {heap 1200k}
{heap 1200k} {heap 1200k} {heap 1616k}
{heap 1616k} {heap 1616k} {heap
1616k}Streaming LTO
{heap 1616k} {heap 1616k} {heap
1616k} {heap 1616k} {heap 1616k} {heap 1616k}
{heap 1616k} {heap 1616k} {heap 1616k} {heap
1616k} {heap 1616k} {heap 1616k}
{heap 1616k} {heap 1616k}Assembling functions:
frob
j.c: In function 'frob':
j.c:7:1: error: unable to find a register to spill
7 | }
| ^
j.c:7:1: error: this is the insn:
(insn 22 26 25 2 (set (mem/c:DI (reg/f:SI 34 .fp) [1 %sfp+-8 S8 A32])
(reg:DI 52)) "j.c":4:7 1 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 52)
(nil)))
during RTL pass: reload
j.c:7:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1837
double frob (double r)
{
r = -r;
return r;
}
[Bug middle-end/85811] Invalid optimization with fmax, fabs and nan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||roger at nextmovesoftware dot com --- Comment #13 from Roger Sayle --- Fixed on mainline. [Sorry I've only just noticed this hadn't been closed].
[Bug c/104399] New: Mingw to generate bogus.o on French locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104399 Bug ID: 104399 Summary: Mingw to generate bogus.o on French locale Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: eric.pouech at orange dot fr Target Milestone: --- after adding one letter to a string inside a .c program, compilation and link fails with: /usr/lib/gcc/i686-w64-mingw32/11.2.1/../../../../i686-w64-mingw32/bin/ld: warning: dlls/dxdiagn/provider.cross.o: local symbol `�' has no section /usr/lib/gcc/i686-w64-mingw32/11.2.1/../../../../i686-w64-mingw32/bin/ld: dlls/dxdiagn/provider.cross.o: unrecognized storage class 0 for *UND* symbol `�' /usr/lib/gcc/i686-w64-mingw32/11.2.1/../../../../i686-w64-mingw32/bin/ld: dlls/dxdiagn/provider.cross.o: could not read symbols: file format not recognized I won't post source code (not because I cannot, but because it won't help). Issue really looks like an issue with generating the .o data inside the file, not the content of the .c file itself. will compare three operations: - make without letter change in .c (good.o) - make with letter change in .c (fail.o) - make with letter change in .c and forcing English locale (LC_ALL=C make) (good-eng.o) (the two first are generated with French locale) [eric]$ echo $LANG fr_FR.utf8 result of compilations: - like the names imply: good.o and good.eng are ok - while fail.o generates the errors above -- doing some binary diffs (%.o => %.txt with xxf %.o %.txt) [eric]$ diff good.txt good-eng.txt 1416,1417c1416,1417 < 5870: 7665 6e64 6f72 2049 4420 3078 2530 3478 vendor ID 0x%04x < 5880: 2e0a 7300 7a00 4d00 6100 6e00 7500 s.z.M.a.n.u. --- > 5870: 7665 6e64 6f72 2049 4420 3078 2530 346c vendor ID 0x%04l > 5880: 782e 0a00 7300 7a00 4d00 6100 6e00 7500 x...s.z.M.a.n.u. that's the only diff; just exposing the change in the string (luckily short-alignment didn't shift the rest of the file) now the diff with the bogus.o file [eric]$ diff -C 3 good.txt fail.txt *** good.txt2022-02-05 18:10:14.103553524 +0100 --- fail.txt2022-02-05 18:10:05.512628736 +0100 *** *** 1413,1420 5840: 7900 7300 4900 6400 7300 7a00 5200 y.s.I.d...s.z.R. 5850: 6500 7600 6900 7300 6900 6f00 6e00 4900 e.v.i.s.i.o.n.I. 5860: 6400 556e 6b6e 6f77 6e20 5043 4920 d...Unknown PCI ! 5870: 7665 6e64 6f72 2049 4420 3078 2530 3478 vendor ID 0x%04x ! 5880: 2e0a 7300 7a00 4d00 6100 6e00 7500 s.z.M.a.n.u. 5890: 6600 6100 6300 7400 7500 7200 6500 7200 f.a.c.t.u.r.e.r. 58a0: 2500 6400 2000 7800 2000 2500 %.d. .x. .%. 58b0: 6400 2000 2800 2500 6400 2000 6200 6900 d. .(.%.d. .b.i. --- 1413,1420 5840: 7900 7300 4900 6400 7300 7a00 5200 y.s.I.d...s.z.R. 5850: 6500 7600 6900 7300 6900 6f00 6e00 4900 e.v.i.s.i.o.n.I. 5860: 6400 556e 6b6e 6f77 6e20 5043 4920 d...Unknown PCI ! 5870: 7665 6e64 6f72 2049 4420 3078 2530 346c vendor ID 0x%04l ! 5880: 782e 0a00 7300 7a00 4d00 6100 6e00 7500 x...s.z.M.a.n.u. 5890: 6600 6100 6300 7400 7500 7200 6500 7200 f.a.c.t.u.r.e.r. 58a0: 2500 6400 2000 7800 2000 2500 %.d. .x. .%. 58b0: 6400 2000 2800 2500 6400 2000 6200 6900 d. .(.%.d. .b.i. *** *** 15025,15031 0003ab00: 41c5 0c04 042c 00e8 0500 0034 4f00 A,...4O. 0003ab10: 0074 0100 410e 0885 0242 0d05 4687 .tAB..F. 0003ab20: 0386 0483 0502 740a c341 c641 c741 c50c ..t..A.A.A.. ! 0003ab30: 0404 480b 2300 9800 ..H.#... 0003ab40: 0600 f000 9900 0600 1301 0003ab50: 9800 0600 d001 9900 0600 0003ab60: f901 b900 1400 0202 9900 --- 15025,15031 0003ab00: 41c5 0c04 042c 00e8 0500 0034 4f00 A,...4O. 0003ab10: 0074 0100 410e 0885 0242 0d05 4687 .tAB..F. 0003ab20: 0386 0483 0502 740a c341 c641 c741 c50c ..t..A.A.A.. ! 0003ab30: 0404 480b 0041 0e08 2300 9800 ..H..A..#... 0003ab40: 0600 f000 9900 0600 1301 0003ab50: 9800 0600 d001 9900 0600 0003ab60: f901 b900 1400 0202 9900 *** *** 18782,18790 000495d0: 1400 1c05 3600 1400 4805 6.H. 000495e0: 3600 1400 8805 3600 ..6.6... 000495f0: 1400 b805 3600 1400 ec05 ..6. ! 00049600: 3600 1400 2e66 696c 6500 6..file. ! 00049610: feff 6701 7072 6f76 6964 6572 ..g.provider ! 00049620: 2e63 7200 .cr. 00049630: 0100 2000 0301
[Bug c++/104398] New: [c++20] ICE triggered by templated class with base class containing `using enum`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104398
Bug ID: 104398
Summary: [c++20] ICE triggered by templated class with base
class containing `using enum`
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doodspav at gmail dot com
Target Milestone: ---
This code triggers an internal compiler error:
struct E {
enum class type : unsigned char { UNKNOWN };
};
struct T {
using enum E::type;
};
template
struct U : T
{
int ice(int x) {
return static_cast(UNKNOWN);
}
};
int main() {
U<3>().ice(3);
}
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --disable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-2V7zgg/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-2V7zgg/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~20.04)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE using_enum.cpp -mtune=generic -march=x86-64
-std=c++20 -fpch-preprocess -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection
-fcf-protection -o a-using_enum.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/11"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/11
/usr/include/x86_64-linux-gnu/c++/11
/usr/include/c++/11/backward
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -fpreprocessed a-using_enum.ii -quiet
-dumpdir a- -dumpbase using_enum.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -std=c++20 -version -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection
-fcf-protection -o a-using_enum.s
GNU C++20 (Ubuntu 11.1.0-1ubuntu1~20.04) version 11.1.0 (x86_64-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (Ubuntu 11.1.0-1ubuntu1~20.04) version 11.1.0 (x86_64-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7a79b9a038c6e5e716b693fdb4982943
using_enum.cpp: In instantiation of ‘int U::ice(int) [with int N = 3]’:
using_enum.cpp:19:15: required from here
using_enum.cpp:13:16: internal compiler error: in tsubst_copy, at cp/pt.c:16715
13 | return static_cast(UNKNOWN);
|^
0xe306b3 internal_error(char const*, ...)
???:0
0xe27039 fancy_abort(char const*, int, char const*)
???:0
0x10ed884
[Bug c++/104397] Wrong warning message about global static variable in module(.hpp, .cpp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104397 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The warning is correct. While static int a; var is used in class.cpp, you have another copy of that in the main.cpp TU, and there it is defined but unused.
[Bug c++/104008] [11/12 Regression] New g++ folly compile error with gcc 11.x. Bisected to PR99445 c++: Alias template in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 --- Comment #5 from Alex Hornby --- (In reply to Alex Hornby from comment #3) > Created attachment 52356 [details] > preprocessed source from gcc 10.3.0 done, also captured the source from a failing 11.2.1 build at same system state
[Bug c++/104008] [11/12 Regression] New g++ folly compile error with gcc 11.x. Bisected to PR99445 c++: Alias template in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 --- Comment #4 from Alex Hornby --- Created attachment 52357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52357=edit preprocessed source from gcc 11.2.1 produced at same time as gcc 10.3.0 preprocessed source captured at the same system state as the 10.3.0 pre-processed source from my Fedora 35 system
[Bug c++/104008] [11/12 Regression] New g++ folly compile error with gcc 11.x. Bisected to PR99445 c++: Alias template in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 --- Comment #3 from Alex Hornby --- Created attachment 52356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52356=edit preprocessed source from gcc 10.3.0
[Bug tree-optimization/104389] [12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[12 Regression] HUGE_VAL * |HUGE_VAL * 0.0 is no longer |0.0 is no longer a NaN |a NaN | Target Milestone|10.4|12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Turns out this isn't a problem on 10/11 branches.
[Bug tree-optimization/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b3763384a1f696260f3ee7bda8c0e7e4ad732ad9 commit r12-7072-gb3763384a1f696260f3ee7bda8c0e7e4ad732ad9 Author: Jakub Jelinek Date: Sat Feb 5 10:52:19 2022 +0100 match.pd: Fix x * 0.0 -> 0.0 folding [PR104389] The recent PR95115 change to punt in const_binop on folding operation with non-NaN operands into NaN if flag_trapping_math broke the following testcase, because the x * 0.0 simplification punts just if x maybe a NaN (because NaN * 0.0 is NaN not 0.0) or if one of the operands could be negative zero. But Inf * 0.0 or -Inf * 0.0 is also NaN, not 0.0, so when NaNs are honored we need to punt for possible infinities too. 2022-02-05 Jakub Jelinek PR tree-optimization/104389 * match.pd (x * 0 -> 0): Punt if x maybe infinite and NaNs are honored. * gcc.dg/pr104389.c: New test.
[Bug c++/104397] Wrong warning message about global static variable in module(.hpp, .cpp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104397 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-02-05 --- Comment #1 from Andrew Pinski --- This does not use modules though: g++ -Wall class.hpp class.cpp main.cpp -o main This just uses precompiled headers. As shown by: #pragma GCC pch_preprocess "class.hpp.gch" This means the a is defined but not used. See https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/C_002b_002b-Modules.html#C_002b_002b-Modules on how to use modules rather than precompiled headers.
[Bug c++/104397] New: Wrong warning message about global static variable in module(.hpp, .cpp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104397
Bug ID: 104397
Summary: Wrong warning message about global static variable in
module(.hpp, .cpp)
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bogdasar1985 at gmail dot com
Target Milestone: ---
Created attachment 52355
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52355=edit
Output of "gcc -v -save-temps all-your-options source-file && neofetch
--stdout"
class.hpp
-
#ifndef CLASS
#define CLASS
static int a;
class Class
{
public:
Class();
~Class();
private:
int b;
int c;
};
#endif
class.cpp
---
#include "class.hpp"
#include
Class::Class() : b(0), c(0)
{
a++;
printf("%d\n", a);
};
Class::~Class()
{
printf("%d\n", a);
a--;
}
main.cpp
-
#include "class.hpp"
int main()
{
Class a, b, c, d;
return 0;
}
Compiling that by command:
g++ -Wall class.hpp class.cpp main.cpp -o main
generate next warning:
class.hpp:3:12: warning: ‘a’ defined but not used [-Wunused-variable]
3 | static int a;
|^
which is wrong, because variable a used for output.
Output of
gcc -v -save-temps all-your-options source-file && neofetch --stdout
in attachment file.
class.ii
# 1 "class.hpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "class.hpp"
static int a;
class Class
{
public:
Class();
~Class();
private:
int b;
int c;
};
main.ii
-
# 1 "main.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "main.cpp"
#pragma GCC pch_preprocess "class.hpp.gch"
int main()
{
Class a, b, c, d;
return 0;
}
[Bug libstdc++/104395] ext/bitmap_allocator.h is not C++98 friendly when using with -faligned-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > GCC's option is -faligned-new -fsized-deallocation -std=c++98 yeah gcc does not work either.
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 --- Comment #9 from Fedor Chelnokov --- There is a related discussion: https://stackoverflow.com/a/47618530/7325599 And it is noted there that according to [over.ics.rank]/2 just before [over.ics.rank]/3: — a standard conversion sequence is a better conversion sequence than a user-defined conversion
[Bug target/104219] [12 regression] riscv64 compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 --- Comment #4 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:06e32a5ebf20c11dd31bc2677bede569fef84316 commit r12-7070-g06e32a5ebf20c11dd31bc2677bede569fef84316 Author: Kito Cheng Date: Tue Jan 25 20:44:04 2022 +0800 RISC-V: Always pass -misa-spec to assembler [PR104219] Add -misa-spec to OPTION_DEFAULT_SPECS to make sure -misa-spec will always pass that into assembler, that prevent GCC and binutils using different way to interpret the ISA string. gcc/ChangeLog: PR target/104219 * config.gcc (riscv*-*-*): Normalize the with_isa_spec value. (all_defaults): Add isa_spec. * config/riscv/riscv.h (OPTION_DEFAULT_SPECS): Add isa_spec.
[Bug target/104396] [11/12 Regression] Invalid SIMD intriniscs accepted at -O1 and above after r11-6794-g04b472ad0e1dc93aba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104396 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3
[Bug target/104396] New: [11/12 Regression] Invalid SIMD intriniscs accepted at -O1 and above after r11-6794-g04b472ad0e1dc93aba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104396
Bug ID: 104396
Summary: [11/12 Regression] Invalid SIMD intriniscs accepted at
-O1 and above after r11-6794-g04b472ad0e1dc93aba
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Take:
#include
void f(int32x4_t *p0, int16x8_t *p1) {
vqdmlal_high_laneq_s16(p0[0], p1[0], p1[1], -1);
}
This should be rejected even at -O1 but after r11-6794-g04b472ad0e1dc93aba, it
is accepted as the builtin is now removed with DCE.
See https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589911.html also.
[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #14 from Sergey Fedorov --- (In reply to Vladimir Makarov from comment #13) > I think there are two code spots whose pitfalls resulted in the PR. > > The first one is in rs6000.cc::legitimate_lo_sum_address_p which permits > wrong pic low-sum address. > > Another one is in lra-constraints.cc::process_address_1 which permits put > wrong low-sum address in reg and use the reg in memory. > > The following patch solves the problem: Does this also address Bug 104118? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104118
