[Bug gcov-profile/97065] New: Support -fprofile-update=set (boolean counters)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97065 Bug ID: 97065 Summary: Support -fprofile-update=set (boolean counters) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me CC: marxin at gcc dot gnu.org Target Milestone: --- I can understand that defaulting -fprofile-update=prefer-atomic in GCC 7 and using atomic counters when -pthread is specified is for very good reasons that imprecise line execution counts can be very confusing. However, atomic counters can lead to very drastic performance degradation when the contention is large (e.g. bug 80952) Sometimes users just need to know whether a statement is executed or not. For example lcov does not really need to know the number. A boolean mode -fprofile-update=set may be useful. 'set' is the name used by Go -covermode=set
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654 --- Comment #4 from Tobias Burnus --- (In reply to Tobias Burnus from comment #3) > Created attachment 49222 [details] > Slightly reduced example, compile with gfortran -fopenmp -O1 -ftracer On the host side, a single BB gets inserted – but more interesting is the device side: For the nvptx lto1, all dumped trees are identical until profile_estimate. The result (the non-64 value) slightly varies, but one can disable disable app three passes until tree-tracer to get still a fail: gfortran -fopenmp -ftracer -O1 test.f90 -foffload='-fdisable-tree-dom3 -fdisable-tree-profile_estimate -fdisable-tree-fixup_cfg3 -fdisable-tree-strlen1 -fdisable-tree-copyprop5 -fdisable-tree-wrestr^Ct -fdisable-tree-dse3 -fdump-tree-all -fdisable-tree-cddce3 -fdisable-tree-forwprop4 -fdisable-tree-phiopt4 -fdisable-tree-fab1 -fdisable-tree-dce7 -fdisable-tree-crited1 -fdisable-tree-uncprop1 -fdisable-tree-local-pure-const2 -fdisable-tree-nrv -fdisable-tree-isel -fdisable-tree-optimized' Adding -foffload=-fdisable-tree-tracer unsurprisingly makes all tree dumps identical and yields the expected 64.
[Bug tree-optimization/97066] New: GCC11 regression caused by r11-3207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97066 Bug ID: 97066 Summary: GCC11 regression caused by r11-3207 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com CC: fxue at os dot amperecomputing.com Target Milestone: --- Host: x86_64-pc-linux-gnu Commit r11-3207 caused. FAIL: gcc.dg/tree-ssa/20030807-10.c scan-tree-dump-times vrp1 " >> 2" 1 FAIL: gcc.dg/tree-ssa/20030807-10.c scan-tree-dump-times vrp1 " & 3" 1 FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made" with gcc configure as ../../gcc/configure --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-3207/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
[Bug tree-optimization/97066] [11 Regression] regression caused by r11-3207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97066 Richard Biener changed: What|Removed |Added Summary|GCC11 regression caused by |[11 Regression] regression |r11-3207|caused by r11-3207 Target Milestone|--- |11.0
[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987
--- Comment #4 from Iain Buclaw ---
And what about void pointers? How is it assumed that the pointed to object is
read when it has no value?
Expanded example loosely rewritten from the original library code.
---
void GC_addRange(const void * const, __SIZE_TYPE__);
struct VoidArray
{
__SIZE_TYPE__ length;
void *ptr;
};
// struct Array(T) {
#define T int
bool isInitialized;
VoidArray _data;
__SIZE_TYPE__ _capacity;
void
reserve (__SIZE_TYPE__ elements)
{
if (!isInitialized)
{
if (!elements) return;
__SIZE_TYPE__ sz;
int overflow = __builtin_mul_overflow (elements, sizeof (T), &sz);
if (overflow) __builtin_abort ();
void *p = __builtin_malloc (sz);
if (!p) __builtin_abort ();
// static if (hasIndirections!T) {
GC_addRange (p, sz);
// }
_data.ptr = p;
_data.length = 0;
_capacity = elements;
}
else
{
// _data.reserve (elements);
}
}
// };
[Bug gcov-profile/97065] Support -fprofile-update=set (boolean counters)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97065 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bd909071ac04e94f4b6f0baab64d0687ec55681d
commit r11-3219-gbd909071ac04e94f4b6f0baab64d0687ec55681d
Author: Jakub Jelinek
Date: Wed Sep 16 09:42:33 2020 +0200
store-merging: Consider also overlapping stores earlier in the by bitpos
sorting [PR97053]
As the testcases show, if we have something like:
MEM [&b + 8B] = {};
MEM[(short *) &b] = 5;
_5 = *x_4(D);
MEM [&b + 2B] = _5;
MEM[(char *)&b + 16B] = 88;
MEM[(int *)&b + 20B] = 1;
then in sort_by_bitpos the stores are almost like in the given order,
except the first store is after the = _5; store.
We can't coalesce the = 5; store with = _5;, because the latter is MEM_REF,
while the former INTEGER_CST, and we can't coalesce the = _5 store with
the = {} store because the former is MEM_REF, the latter INTEGER_CST.
But we happily coalesce the remaining 3 stores, which is wrong, because the
= _5; store overlaps those and is in between them in the program order.
We already have code to deal with similar cases in check_no_overlap, but we
deal only with the following stores in sort_by_bitpos order, not the
earlier
ones.
The following patch checks also the earlier ones. In
coalesce_immediate_stores
it computes the first one that needs to be checked (all the ones whose
bitpos + bitsize is smaller or equal to merged_store->start don't need to
be
checked and don't need to be checked even for any following attempts
because
of the sort_by_bitpos sorting) and the end of that (that is the first store
in the merged_store).
2020-09-16 Jakub Jelinek
PR tree-optimization/97053
* gimple-ssa-store-merging.c (check_no_overlap): Add FIRST_ORDER,
START, FIRST_EARLIER and LAST_EARLIER arguments. Return false if
any stores between FIRST_EARLIER inclusive and LAST_EARLIER
exclusive
has order in between FIRST_ORDER and LAST_ORDER and overlaps the to
be merged store.
(imm_store_chain_info::try_coalesce_bswap): Add FIRST_EARLIER
argument.
Adjust check_no_overlap caller.
(imm_store_chain_info::coalesce_immediate_stores): Add
first_earlier
and last_earlier variables, adjust them during iterations. Adjust
check_no_overlap callers, call check_no_overlap even when extending
overlapping stores by extra INTEGER_CST stores.
* gcc.dg/store_merging_31.c: New test.
* gcc.dg/store_merging_32.c: New test.
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7e97e7470e74b0d9a68000938a359a7049774d77
commit r10-8769-g7e97e7470e74b0d9a68000938a359a7049774d77
Author: Jakub Jelinek
Date: Wed Sep 16 09:42:33 2020 +0200
store-merging: Consider also overlapping stores earlier in the by bitpos
sorting [PR97053]
As the testcases show, if we have something like:
MEM [&b + 8B] = {};
MEM[(short *) &b] = 5;
_5 = *x_4(D);
MEM [&b + 2B] = _5;
MEM[(char *)&b + 16B] = 88;
MEM[(int *)&b + 20B] = 1;
then in sort_by_bitpos the stores are almost like in the given order,
except the first store is after the = _5; store.
We can't coalesce the = 5; store with = _5;, because the latter is MEM_REF,
while the former INTEGER_CST, and we can't coalesce the = _5 store with
the = {} store because the former is MEM_REF, the latter INTEGER_CST.
But we happily coalesce the remaining 3 stores, which is wrong, because the
= _5; store overlaps those and is in between them in the program order.
We already have code to deal with similar cases in check_no_overlap, but we
deal only with the following stores in sort_by_bitpos order, not the
earlier
ones.
The following patch checks also the earlier ones. In
coalesce_immediate_stores
it computes the first one that needs to be checked (all the ones whose
bitpos + bitsize is smaller or equal to merged_store->start don't need to
be
checked and don't need to be checked even for any following attempts
because
of the sort_by_bitpos sorting) and the end of that (that is the first store
in the merged_store).
2020-09-16 Jakub Jelinek
PR tree-optimization/97053
* gimple-ssa-store-merging.c (check_no_overlap): Add FIRST_ORDER,
START, FIRST_EARLIER and LAST_EARLIER arguments. Return false if
any stores between FIRST_EARLIER inclusive and LAST_EARLIER
exclusive
has order in between FIRST_ORDER and LAST_ORDER and overlaps the to
be merged store.
(imm_store_chain_info::try_coalesce_bswap): Add FIRST_EARLIER
argument.
Adjust check_no_overlap caller.
(imm_store_chain_info::coalesce_immediate_stores): Add
first_earlier
and last_earlier variables, adjust them during iterations. Adjust
check_no_overlap callers, call check_no_overlap even when extending
overlapping stores by extra INTEGER_CST stores.
* gcc.dg/store_merging_31.c: New test.
* gcc.dg/store_merging_32.c: New test.
(cherry picked from commit bd909071ac04e94f4b6f0baab64d0687ec55681d)
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jakub Jelinek --- Should be fixed now for 10.3+ and 11.1+.
[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677
--- Comment #9 from liusujian ---
After lto and as:
/home/lsj/dts/SDK_CPU_RISCV/output/hcc_riscv32/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/as
-v --traditional-format -march=rv32imc -march=rv32imc -mabi=ilp32 -mabi=ilp32
-o extern2.exe.ltrans0.ltrans.o extern2.exe.ltrans0.s
We got the two symbols of _ZN12_GLOBAL__N_12xxE and _ZN12_GLOBAL__N_12xxE.lto:
./riscv32-unknown-elf-readelf -s extern2.exe.ltrans0.ltrans.o
Symbol table '.symtab' contains 21 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT3
4: 0 SECTION LOCAL DEFAULT4
5: 20 FUNCLOCAL DEFAULT1 _ZN12_GLOBAL__N_13fooEv
6: 0 NOTYPE LOCAL DEFAULT1 .L0
7: 0006 0 NOTYPE LOCAL DEFAULT1 .L0
8: 0010 0 NOTYPE LOCAL DEFAULT1 .L0
9: 0014 0 NOTYPE LOCAL DEFAULT1 .L0
10: 0 SECTION LOCAL DEFAULT5
11: 4 OBJECT LOCAL DEFAULT5 _ZN12_GLOBAL__N_12xxE.lto
12: 0014 0 NOTYPE LOCAL DEFAULT1 .L0
13: 001a 0 NOTYPE LOCAL DEFAULT1 .L0
14: 002a 0 NOTYPE LOCAL DEFAULT1 .L0
15: 002e 0 NOTYPE LOCAL DEFAULT1 .L0
16: 0 SECTION LOCAL DEFAULT6
17: 0 SECTION LOCAL DEFAULT7
18: 0 SECTION LOCAL DEFAULT9
19: 0 NOTYPE GLOBAL DEFAULT UND _ZN12_GLOBAL__N_12xxE
20: 001426 FUNCGLOBAL DEFAULT1 main
We found that by GDB ,it renamed by the function of rename_statics in
gcc\lto\lto-partition.c. Here is the function body of rename_statics:
---
/* If NODE represents a static variable. See if there are other variables
of the same name in partition ENCODER (or in whole compilation unit if
ENCODER is NULL) and if so, mangle the statics. Always mangle all
conflicting statics, so we reduce changes of silently miscompiling
asm statements referring to them by symbol name. */
static void
rename_statics (lto_symtab_encoder_t encoder, symtab_node *node)
{
tree decl = node->decl;
symtab_node *s;
tree name = DECL_ASSEMBLER_NAME (decl);
/* See if this is static symbol. */
if (((node->externally_visible && !node->weakref)
/* FIXME: externally_visible is somewhat illogically not set for
external symbols (i.e. those not defined). Remove this test
once this is fixed. */
|| DECL_EXTERNAL (node->decl)
|| !node->real_symbol_p ())
&& !may_need_named_section_p (encoder, node))
return;
/* Now walk symbols sharing the same name and see if there are any conflicts.
(all types of symbols counts here, since we can not have static of the
same name as external or public symbol.) */
for (s = symtab_node::get_for_asmname (name);
s; s = s->next_sharing_asm_name)
if ((s->real_symbol_p () || may_need_named_section_p (encoder, s))
&& s->decl != node->decl
&& (!encoder
|| lto_symtab_encoder_lookup (encoder, s) != LCC_NOT_FOUND))
break;
/* OK, no confict, so we have nothing to do. */
if (!s)
return;
if (symtab->dump_file)
fprintf (symtab->dump_file,
"Renaming statics with asm name: %s\n", node->name ());
/* Assign every symbol in the set that shares the same ASM name an unique
mangled name. */
for (s = symtab_node::get_for_asmname (name); s;)
if ((!s->externally_visible || s->weakref)
/* Transparent aliases having same name as target are renamed at a
time their target gets new name. Transparent aliases that use
separate assembler name require the name to be unique. */
&& (!s->transparent_alias || !s->definition || s->weakref
|| !symbol_table::assembler_names_equal_p
(IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (s->decl)),
IDENTIFIER_POINTER
(DECL_ASSEMBLER_NAME (s->get_alias_target()->decl
&& ((s->real_symbol_p ()
&& !DECL_EXTERNAL (s->decl)
&& !TREE_PUBLIC (s->decl))
|| may_need_named_section_p (encoder, s))
&& (!encoder
|| lto_symtab_encoder_lookup (encoder, s) != LCC_NOT_FOUND))
{
if (privatize_symbol_name (s))
/* Re-start from beginning since we do not know how many
symbols changed a name. */
s = symtab_node::get_for_asmname (name);
else s = s->next_sharing_asm_name;
}
else s = s->next_sharing_asm_name;
}
---
The
[Bug tree-optimization/97066] [11 Regression] regression caused by r11-3207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97066 --- Comment #1 from Feng Xue --- Both cases will be simplified with new pattern, and this is correct. Will change test code to make that not happen.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 --- Comment #2 from Jiri Olsa --- Created attachment 49223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49223&action=edit fs/init.i
[Bug testsuite/97066] [11 Regression] regression caused by r11-3207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97066 fxue at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |testsuite Last reconfirmed||2020-09-16 Assignee|unassigned at gcc dot gnu.org |fxue at os dot amperecomputing.com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||fxue at gcc dot gnu.org
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Status|WAITING |NEW
--- Comment #3 from Jakub Jelinek ---
So this is really just something like: -O2 -g -dA:
extern int foo (unsigned int, unsigned int);
int
bar (void)
{
foo (1, 2);
return 0;
}
where we don't emit DW_AT_declaration neither for the external declaration of
foo, nor for the definition of bar. Other compilers don't emit them either.
Anyway, older gcc versions used to emit those and this changed with
PR96383 r11-2455-gc6ef9d8d3f11221df1ea6358b8d4e79e42f074fb
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
--- Comment #4 from Jiri Olsa ---
(In reply to Jakub Jelinek from comment #3)
> So this is really just something like: -O2 -g -dA:
> extern int foo (unsigned int, unsigned int);
>
> int
> bar (void)
> {
> foo (1, 2);
> return 0;
> }
>
> where we don't emit DW_AT_declaration neither for the external declaration
> of foo, nor for the definition of bar. Other compilers don't emit them
> either.
>
> Anyway, older gcc versions used to emit those and this changed with
> PR96383 r11-2455-gc6ef9d8d3f11221df1ea6358b8d4e79e42f074fb
is there a way we can tell which record is for declaration/definition?
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
--- Comment #5 from Jakub Jelinek ---
So perhaps completely untested:
--- gcc/dwarf2out.c.jj 2020-09-07 13:17:58.383594248 +0200
+++ gcc/dwarf2out.c 2020-09-16 10:53:44.353632197 +0200
@@ -26547,7 +26547,8 @@ dwarf2out_early_global_decl (tree decl)
&& ((origin_die = lookup_decl_die (origin)) == NULL
|| is_declaration_die (origin_die)))
{
- current_function_decl = origin;
+ current_function_decl
+ = DECL_EXTERNAL (origin) ? NULL_TREE : origin;
dwarf2out_decl (origin);
}
@@ -26556,7 +26557,7 @@ dwarf2out_early_global_decl (tree decl)
if ((old_die = lookup_decl_die (decl)) == NULL
|| is_declaration_die (old_die))
{
- current_function_decl = decl;
+ current_function_decl = DECL_EXTERNAL (decl) ? NULL_TREE : decl;
dwarf2out_decl (decl);
}
?
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 Jakub Jelinek changed: What|Removed |Added Version|10.2.1 |11.0 --- Comment #6 from Jakub Jelinek --- Also, to avoid confusion, upstream 10 branch is not affected, but in 10-RH we've backported the PR96383 changes from the trunk.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 49224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49224&action=edit gcc11-pr97060.patch Actually, the DECL_EXTERNAL tests aren't probably a good idea because of the GNU extern inlines. This patch attempts to match the previous behavior where early_debug_decl was called only on FUNCTION_DECLs with gimple bodies, so the patch for those keeps setting current_function_decl to non-NULL and sets it to NULL only for the FUNCTION_DECLs for which it wouldn't be called previously and only the PR96383 changed that.
[Bug sanitizer/97067] New: UBSAN: False positive maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97067
Bug ID: 97067
Summary: UBSAN: False positive maybe-uninitialized
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.lebourlot at starqube dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Compiling with -Wall -fsanitize=undefined the following code causes a false
positive:
```
void nothing(){return;}
int toto=[](){nothing();return 0;}();
int main(){return 0;}
warnings are:
main.cpp: In function ‘void __static_initialization_and_destruction_0(int,
int)’:
main.cpp:3:35: warning: ‘’ may be used uninitialized
[-Wmaybe-uninitialized]
3 | int toto=[](){nothing();return 0;}();
| ~^~
main.cpp:3:10: note: by argument 1 of type ‘const*’ to ‘’
declared here
3 | int toto=[](){nothing();return 0;}();
| ^
main.cpp:3:10: note: ‘’ declared here
3 | int toto=[](){nothing();return 0;}();
| ^
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 Kewen Lin changed: What|Removed |Added Last reconfirmed||2020-09-16 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #7 from Kewen Lin --- Two questions in mind, need to dig into it further: 1) from the assembly of scalar/vector code, I don't see any stores needed into temp array d (array diff in pixel_sub_wxh), but when modeling we consider the stores. On Power two vector stores take cost 2 while 16 scalar stores takes cost 16, it seems wrong to cost model something useless. Later, for the vector version we need 16 vector halfword extractions from these two halfword vectors, while scalar version the values are just in GPR register, vector version looks inefficient. 2) on Power, the conversion from unsigned char to unsigned short is nop conversion, when we counting scalar cost, it's counted, then add costs 32 totally onto scalar cost. Meanwhile, the conversion from unsigned short to signed short should be counted but it's not (need to check why further). The nop conversion costing looks something we can handle in function rs6000_adjust_vect_cost_per_stmt, I tried to use the generic function tree_nop_conversion_p, but it's only for same mode/precision conversion. Will find/check something else.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #8 from Richard Biener --- (In reply to Kewen Lin from comment #7) > Two questions in mind, need to dig into it further: > 1) from the assembly of scalar/vector code, I don't see any stores needed > into temp array d (array diff in pixel_sub_wxh), but when modeling we > consider the stores. Because when modeling they are still there. There's no good way around this. > On Power two vector stores take cost 2 while 16 scalar > stores takes cost 16, it seems wrong to cost model something useless. Later, > for the vector version we need 16 vector halfword extractions from these two > halfword vectors, while scalar version the values are just in GPR register, > vector version looks inefficient. > 2) on Power, the conversion from unsigned char to unsigned short is nop > conversion, when we counting scalar cost, it's counted, then add costs 32 > totally onto scalar cost. Meanwhile, the conversion from unsigned short to > signed short should be counted but it's not (need to check why further). > The nop conversion costing looks something we can handle in function > rs6000_adjust_vect_cost_per_stmt, I tried to use the generic function > tree_nop_conversion_p, but it's only for same mode/precision conversion. > Will find/check something else.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
--- Comment #8 from Jakub Jelinek ---
Unfortunately the patch doesn't really bootstrap.
Small testcase that ICEs:
struct S { virtual ~S (); } s;
This is on the external S::~S() declaration, which has non-NULL
decl_ultimate_origin (the abstract destructor from which the concrete ones are
inherited), but with the above patch we want to emit it as declaration and run
into:
/* A concrete instance, tag a new DIE with DW_AT_abstract_origin. */
if (origin != NULL)
{
gcc_assert (!declaration || local_scope_p (context_die));
So, one way around would be to only clear current_function_decl for functions
with decl_ultimate_origin (decl) == NULL.
But then we wouldn't emit DW_AT_declaration in this case (ok, one needs
-fno-eliminate-unused-debug-symbols to actually see it in the assembly).
On the other side, having a DW_TAG_subprogram with both DW_AT_specification and
DW_AT_declaration looks invalid to me.
[Bug demangler/97068] New: Can't demangle a certain symbl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97068 Bug ID: 97068 Summary: Can't demangle a certain symbl Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: cbiesinger at google dot com Target Milestone: --- (gdb) demangle _ZN4base8OptionalIN5blink10TestStructEEaSIRS2_EENSt4__Cr9enable_ifIXaantsr3std7is_sameINS6_9remove_cvINS6_16remove_referenceIT_E4typeEE4typeES3_EE5valuesr3std16is_constructibleIS2_SA_EE5valuesr3std13is_assignableIS5_SA_EE5valueoontL_ZNS6_17integral_constantIbLb0EE5valueEEntsr3std7is_sameINS6_5decayISA_E4typeES2_EE5valueERS3_E4typeEOSA_ Can't demangle "_ZN4base8OptionalIN5blink10TestStructEEaSIRS2_EENSt4__Cr9enable_ifIXaantsr3std7is_sameINS6_9remove_cvINS6_16remove_referenceIT_E4typeEE4typeES3_EE5valuesr3std16is_constructibleIS2_SA_EE5valuesr3std13is_assignableIS5_SA_EE5valueoontL_ZNS6_17integral_constantIbLb0EE5valueEEntsr3std7is_sameINS6_5decayISA_E4typeES2_EE5valueERS3_E4typeEOSA_" (gdb) However: llvm-cxxfilt-9 _ZN4base8OptionalIN5blink10TestStructEEaSIRS2_EENSt4__Cr9enable_ifIXaantsr3std7is_sameINS6_9remove_cvINS6_16remove_referenceIT_E4typeEE4typeES3_EE5valuesr3std16is_constructibleIS2_SA_EE5valuesr3std13is_assignableIS5_SA_EE5valueoontL_ZNS6_17integral_constantIbLb0EE5valueEEntsr3std7is_sameINS6_5decayISA_E4typeES2_EE5valueERS3_E4typeEOSA_ std::__Cr::enable_if<(((!(std::is_same::type>::type, base::Optional >::value)) && (std::is_constructible::value)) && (std::is_assignable::value)) && ((!(std::__Cr::integral_constant::value)) || (!(std::is_same::type, blink::TestStruct>::value))), base::Optional&>::type base::Optional::operator=(blink::TestStruct&)
[Bug testsuite/97066] [11 Regression] regression caused by r11-3207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97066 --- Comment #2 from CVS Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:f419a0158950034ed9996ae860b0c8df03731119 commit r11-3228-gf419a0158950034ed9996ae860b0c8df03731119 Author: Feng Xue Date: Wed Sep 16 16:21:14 2020 +0800 testsuite/97066 - minor change to bypass plusminus-with-convert rule The following testcases will be simplified by the new rule (T)(A) +- (T)(B) -> (T)(A +- B), so could not keep code pattern expected by test-check. Adjust test code to suppress simplification. 2020-09-16 Feng Xue gcc/testsuite/ PR testsuite/97066 * gcc.dg/ifcvt-3.c: Modified to suppress simplification. * gcc.dg/tree-ssa/20030807-10.c: Likewise.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #9 from Kewen Lin --- (In reply to Richard Biener from comment #8) > (In reply to Kewen Lin from comment #7) > > Two questions in mind, need to dig into it further: > > 1) from the assembly of scalar/vector code, I don't see any stores needed > > into temp array d (array diff in pixel_sub_wxh), but when modeling we > > consider the stores. > > Because when modeling they are still there. There's no good way around this. > I noticed the stores get eliminated during FRE. Can we consider running FRE once just before SLP? a bad idea due to compilation time?
[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032 --- Comment #4 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:453a20c65722719b9e2d84339f215e7ec87692dc commit r11-3229-g453a20c65722719b9e2d84339f215e7ec87692dc Author: H.J. Lu Date: Mon Sep 14 08:52:27 2020 -0700 rtl_data: Add sp_is_clobbered_by_asm Add sp_is_clobbered_by_asm to rtl_data to inform backends that the stack pointer is clobbered by asm statement. gcc/ PR target/97032 * cfgexpand.c (asm_clobber_reg_kind): Set sp_is_clobbered_by_asm to true if the stack pointer is clobbered by asm statement. * emit-rtl.h (rtl_data): Add sp_is_clobbered_by_asm. * config/i386/i386.c (ix86_get_drap_rtx): Set need_drap to true if the stack pointer is clobbered by asm statement. gcc/testsuite/ PR target/97032 * gcc.target/i386/pr97032.c: New test.
[Bug gcov-profile/97069] New: Zero valued #line directive results in excessively large blocks of memory being allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97069
Bug ID: 97069
Summary: Zero valued #line directive results in excessively
large blocks of memory being allocated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: martin.ogden at arm dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 49225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49225&action=edit
Associated main.i file
Adding a #line directive with a line number of 0 causes gcov to attempt to
allocate large (~2G) blocks of memory. To reproduce, consider main.c:
int main()
{
}
#line 0 "main.c"
void zero_line_directive()
{
}
Compile and attempt to run gcov:
$ gcc main.c -Wall -Werror --coverage
$ ./a.out
$ gcov main.c # gcov a-main.c for gcc-11
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
The bad allocation is made in gcc/gcc/gcov.c at line 1346:
s->lines.resize(last_line + 1);
A line number of 0 causes `last_line` to be large (often 0x10, sometimes
larger ~10^8).
System details
--
Fault occurs on Ubuntu 16.04.6 with with gcc-{5,7,8,9,11} and gcov-{5,7,8,9,11}
(not tested with v{<=4,6,10}).
$ lsb_release -a
...
Distributor ID: Ubuntu
Description:Ubuntu 16.04.6 LTS
Release:16.04
Codename: xenial
$ gcc -v
gcc version 11.0.0 20200902 (experimental) (GCC)
$ gcc-9 -v
gcc-9 (Ubuntu 9.3.0-10ubuntu2~16.04) 9.3.0
$ gcc-8
gcc-8 (Ubuntu 8.1.0-9ubuntu1~16.04.york1) 8.1.0
$ gcc-7 -v
gcc-7 (Ubuntu 7.3.0-23ubuntu2~16.04.york0) 7.3.0
$ gcc-5 -v
gcc-5 (Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010
It also occurs on macOS 10.15.6 with gcc-{7,8,9} (not tested with
v{<=5,6,10,11}).
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
--- Comment #10 from Richard Biener ---
(In reply to Kewen Lin from comment #9)
> (In reply to Richard Biener from comment #8)
> > (In reply to Kewen Lin from comment #7)
> > > Two questions in mind, need to dig into it further:
> > > 1) from the assembly of scalar/vector code, I don't see any stores
> > > needed
> > > into temp array d (array diff in pixel_sub_wxh), but when modeling we
> > > consider the stores.
> >
> > Because when modeling they are still there. There's no good way around
> > this.
> >
>
> I noticed the stores get eliminated during FRE. Can we consider running FRE
> once just before SLP? a bad idea due to compilation time?
Yeah, we already run FRE a lot and it is one of the more expensive passes.
Note there's one point we could do better which is the embedded SESE FRE
run from cunroll which is only run before we consider peeling an outer loop
and thus not for the outermost unrolled/peeled code (but the question would
be from where / up to what to apply FRE to). On x86_64 this would apply to
the unvectorized but then unrolled outer loop from pixel_sub_wxh which feeds
quite bad IL to the SLP pass (but that shouldn't matter too much, maybe it
matters for costing though).
I think I looked at this or a related testcase some time ago and split out
some PRs (can't find those right now). For example we are not considering
to simplify
_318 = {_4, _14, _293, _30, _49, _251, _225, _248, _52, _70, _260, _284,
_100, _117, _134, _151};
vect__5.47_319 = (vector(16) short unsigned int) _318;
_154 = MEM[(pixel *)pix2_58(D) + 99B];
_320 = {_6, _16, _22, _32, _51, _255, _231, _243, _54, _68, _276, _286, _103,
_120, _137, _154};
vect__7.48_321 = (vector(16) short unsigned int) _320;
vect__12.49_322 = vect__5.47_319 - vect__7.48_321;
_317 = BIT_FIELD_REF ;
_315 = BIT_FIELD_REF ;
_313 = BIT_FIELD_REF ;
_311 = BIT_FIELD_REF ;
vect_perm_even_165 = VEC_PERM_EXPR <_317, _315, { 0, 2, 4, 6 }>;
vect_perm_odd_164 = VEC_PERM_EXPR <_317, _315, { 1, 3, 5, 7 }>;
vect_perm_even_163 = VEC_PERM_EXPR <_313, _311, { 0, 2, 4, 6 }>;
vect_perm_odd_156 = VEC_PERM_EXPR <_313, _311, { 1, 3, 5, 7 }>;
down to smaller vectors. Also appearantly the two vector CTORs are not
re-shuffled to vector load + shuffle. In the SLP analysis we end up with
t2.c:12:32: note: Final SLP tree for instance:
t2.c:12:32: note: node 0x436e3c0 (max_nunits=16, refcnt=2)
t2.c:12:32: note: stmt 0 *_11 = _12;
t2.c:12:32: note: stmt 1 *_21 = _71;
...
t2.c:12:32: note: stmt 15 *_160 = _161;
t2.c:12:32: note: children 0x436de70
t2.c:12:32: note: node 0x436de70 (max_nunits=16, refcnt=2)
t2.c:12:32: note: stmt 0 _12 = _5 - _7;
t2.c:12:32: note: stmt 1 _71 = _15 - _17;
...
.c:12:32: note: stmt 15 _161 = _152 - _155;
t2.c:12:32: note: children 0x436ebb0 0x4360b70
t2.c:12:32: note: node 0x436ebb0 (max_nunits=16, refcnt=2)
t2.c:12:32: note: stmt 0 _5 = (short unsigned int) _4;
...
t2.c:12:32: note: stmt 15 _152 = (short unsigned int) _151;
t2.c:12:32: note: children 0x42f1740
t2.c:12:32: note: node 0x42f1740 (max_nunits=16, refcnt=2)
t2.c:12:32: note: stmt 0 _4 = *pix1_57(D);
...
t2.c:12:32: note: stmt 15 _151 = MEM[(pixel *)pix1_295 + 3B];
t2.c:12:32: note: load permutation { 0 1 2 3 16 17 18 19 32 33 34 35 48
49 50 51 }
t2.c:12:32: note: node 0x4360b70 (max_nunits=16, refcnt=2)
t2.c:12:32: note: stmt 0 _7 = (short unsigned int) _6;
...
t2.c:12:32: note: stmt 15 _155 = (short unsigned int) _154;
t2.c:12:32: note: children 0x4360be0
t2.c:12:32: note: node 0x4360be0 (max_nunits=16, refcnt=2)
t2.c:12:32: note: stmt 0 _6 = *pix2_58(D);
...
t2.c:12:32: note: stmt 15 _154 = MEM[(pixel *)pix2_296 + 3B];
t2.c:12:32: note: load permutation { 0 1 2 3 32 33 34 35 64 65 66 67 96
97 98 99 }
the load permutations suggest that splitting the group into 4-lane pieces
would avoid doing permutes but then that would require target support
for V4QI and V4HI vectors. At least the loads could be considered
to be vectorized with strided-SLP, yielding 'int' loads and a vector
build from 4 ints. I'd need to analyze why we do not consider this.
t2.c:50:1: note: Detected interleaving load of size 52
t2.c:50:1: note:_4 = *pix1_57(D);
t2.c:50:1: note:_14 = MEM[(pixel *)pix1_57(D) + 1B];
t2.c:50:1: note:_293 = MEM[(pixel *)pix1_57(D) + 2B];
t2.c:50:1: note:_30 = MEM[(pixel *)pix1_57(D) + 3B];
t2.c:50:1: note:
t2.c:50:1: note:_49 = *pix1_40;
t2.c:50:1: note:_251 = MEM[(pixel *)pix1_40 + 1B];
t2.c:50:1: note:_225 = MEM[(pixel *)pix1_40 + 2B];
t2.c:50:1: note:_248 = MEM[(pixel *)pix1_40 + 3B];
t2.c:50:1: note:
t2.c:50:1: note:_52 = *pix1_264;
t2.c:50:1: note:_70 = MEM[(pixel *)pix1_264 + 1B];
t2.c:50:1: note:_260 = MEM[(pixel *)pix1_264 + 2B];
t2.c:50:1: note:
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #5 from Tom de Vries ---
Minimal example:
...
! { dg-do run }
program main
implicit none
integer :: d1, d2
!$omp target map(from: d1)
!$omp teams distribute parallel do simd default(none) lastprivate(d1) &
!$omp& collapse(2)
do d1 = 0, 31
do d2 = 0, 31
end do
end do
!$omp end target
if (d1 /= 32) stop 3
end program
...
[Bug fortran/97070] New: Discrepancy in results between OpenMP/OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97070 Bug ID: 97070 Summary: Discrepancy in results between OpenMP/OpenACC Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: venetis at ceid dot upatras.gr Target Milestone: --- Created attachment 49226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49226&action=edit Small example showing the problem The attached example produces different results when compiled using gcc 10.2.0 and the OpenACC directives and different results using the OpenMP directives. My understanding is that the two approaches are equivalent and that the OpenMP version produces the correct results, i.e. all elements of array XMO should be 1, of DCP 2, of IS1 3 and of IS2 24. Compiled for OpenMP with: gfortran -O3 -fopenmp -Wall -Wextra test_link.f90 parameters.f90 common_vars.f90 -o test_link Compiled for OpenACC with: gfortran -O3 -fopenacc -Wall -Wextra test_link.f90 parameters.f90 common_vars.f90 -o test_link
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #6 from Tom de Vries ---
Created attachment 49227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49227&action=edit
Dumps for failing test-case
(In reply to Tom de Vries from comment #5)
> Minimal example:
> ...
> ! { dg-do run }
>
> program main
> implicit none
> integer :: d1, d2
> !$omp target map(from: d1)
>
> !$omp teams distribute parallel do simd default(none) lastprivate(d1) &
>
> !$omp& collapse(2)
>
> do d1 = 0, 31
> do d2 = 0, 31
> end do
> end do
> !$omp end target
>
> if (d1 /= 32) stop 3
> end program
> ...
Corresponding dumps.
[Bug c++/97033] g++ hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97033
Kaiyan Chang changed:
What|Removed |Added
CC||changkaiyan at live dot com
--- Comment #2 from Kaiyan Chang ---
The test code is wrong. It should be
> inline int F1 (){ return 0; }
And then the g++ will ok.
[Bug gcov-profile/97069] Zero valued #line directive results in excessively large blocks of memory being allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97069 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Any reason why you want #line 0 ? Files don't really have line number 0...
[Bug rtl-optimization/97071] New: Fails to CSE / inherit constant pool load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071
Bug ID: 97071
Summary: Fails to CSE / inherit constant pool load
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
double foo (double x)
{
return x * -3. + 3.;
}
compiles to
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry foo,.-foo
addis 9,2,.LC0@toc@ha
lfd 12,.LC0@toc@l(9)
addis 9,2,.LC2@toc@ha
lfd 0,.LC2@toc@l(9)
fmadd 1,1,12,0
blr
...
.LC0:
.long 0
.long -1073217536
.align 3
.LC2:
.long 0
.long 1074266112
but CSE or reload inheritance could have replaced the add of + 3. with
subtraction of the available -3. constant. Might be more difficult to
pull off on x86 where the add/mul has memory operands.
[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071
Richard Biener changed:
What|Removed |Added
Target||powerpc64le
Keywords||missed-optimization
--- Comment #1 from Richard Biener ---
Right before combine we see the following, still nicely with REG_EQUAL notes
(insn 7 17 9 2 (set (reg:DF 119)
(mem/u/c:DF (unspec:DI [
(symbol_ref/u:DI ("*.LC0") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL) [0 S8 A64])) "t.c":3:20 533
{*movdf_hardfloat64}
(expr_list:REG_EQUAL (const_double:DF -3.0e+0 [-0x0.cp+2])
(nil)))
(insn 9 7 14 2 (set (reg:DF 121)
(mem/u/c:DF (unspec:DI [
(symbol_ref/u:DI ("*.LC2") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL) [0 S8 A64])) "t.c":3:20 533
{*movdf_hardfloat64}
(expr_list:REG_EQUAL (const_double:DF 3.0e+0 [0x0.cp+2])
(nil)))
(insn 14 9 15 2 (set (reg/i:DF 33 1)
(fma:DF (reg:DF 124)
(reg:DF 119)
(reg:DF 121))) "t.c":4:1 894 {*fmadf4_fpr}
(expr_list:REG_DEAD (reg:DF 124)
(expr_list:REG_DEAD (reg:DF 121)
(expr_list:REG_DEAD (reg:DF 119)
(nil)
eventually the easiest pass to teach this to is fwprop though as it already
works DF DEF -> USE. Alternatively PRE could make the subtract and/or the
negated value anticipated.
[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- REG_EQUAL notes aren't really needed for that, we have functions to query the values from the constant pool for loads from it. So guess it is a matter of looking at the constant pool entry, if the negation of it is already emitted and the current value is not, try if instruction with the negation can be recognized. If neither of the constant pool entries is emitted already, but both are present, it should try to canonicalize to one of them...
[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987 --- Comment #5 from Martin Sebor --- A void pointer is usually cast to one to a complete type that's then used to access the object (e.g., bsearch). But not every instance of every warning should be expected to indicate a bug. Most only suggest that there might be one. The documented purpose of GCC warnings is to "report constructions that are not inherently erroneous but that are risky or suggest there may have been an error." This rare use is one such case. It was considered when the warning was designed and deemed an acceptable trade-off. (The attribute was added to help accommodate it.) If adding support for attribute access to the D front end isn't feasible to mark up the function and avoid the warning that way, I would suggest removing the const qualifier from the pointer (following the practice of the C++ standard garbage collector APIs) or providing an non-const overload. Alternatively, writing into a byte of the allocated memory will prevent the warning as well.
[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071 --- Comment #3 from Richard Biener --- So on targets where the FP constant loads are separate insns the load of the negated constant could be replaced by a (neg:DF ..) which might even be profitable when not combined with the following add. As said targets like x86 might be more difficult in this regard though it looks like the memory operands in this case only appear during LRA.
[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071 --- Comment #4 from Richard Biener --- (In reply to Jakub Jelinek from comment #2) > REG_EQUAL notes aren't really needed for that, we have functions to query > the values from the constant pool for loads from it. > So guess it is a matter of looking at the constant pool entry, if the > negation of it is already emitted and the current value is not, try if > instruction with the negation can be recognized. > If neither of the constant pool entries is emitted already, but both are > present, it should try to canonicalize to one of them... Note it's not mainly about optimizing the size of the constant pool but to reduce the number of loads from it and eventually shrink code size.
[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071
--- Comment #5 from Richard Biener ---
Related and more difficult case where the add is first and we'd want to
change the load of -3 to a load of 3 so we can CSE the 3 for the
multiplication.
double foo (double x)
{
return (x + -3.) * 3.;
}
[Bug fortran/97061] [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97061 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:91347c3bbf788ede4af89f46206991c47fa8aceb commit r11-3232-g91347c3bbf788ede4af89f46206991c47fa8aceb Author: Tobias Burnus Date: Wed Sep 16 16:23:13 2020 +0200 Fortran: OpenMP - fix simd with (last)private (PR97061) gcc/fortran/ChangeLog: PR fortran/97061 * trans-openmp.c (gfc_trans_omp_do): Handle simd with (last)private. gcc/testsuite/ChangeLog: PR fortran/97061 * gfortran.dg/gomp/openmp-simd-6.f90: New test.
[Bug gcov-profile/97069] Zero valued #line directive results in excessively large blocks of memory being allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97069 --- Comment #2 from Martin Ogden --- I appreciate `#line 0 "main.c"` doesn't make much sense, but according to https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html, 0 is a valid input.
[Bug fortran/97061] [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97061 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Tobias Burnus --- FIXED.
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #7 from Tom de Vries ---
Minimal example after commit 91347c3bbf7 "Fortran: OpenMP - fix simd with
(last)private (PR97061)":
...
! { dg-do run }
program main
implicit none
integer :: d1
!$omp target map(from: d1)
!$omp teams distribute parallel do simd default(none) lastprivate(d1)
do d1 = 0, 31
end do
!$omp end target
if (d1 /= 32) stop 3
end program
...
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #8 from Tom de Vries ---
Created attachment 49228
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49228&action=edit
Dumps for failing test-case (no collapse case)
(In reply to Tom de Vries from comment #7)
> Minimal example after commit 91347c3bbf7 "Fortran: OpenMP - fix simd with
> (last)private (PR97061)":
> ...
> ! { dg-do run }
>
> program main
> implicit none
> integer :: d1
> !$omp target map(from: d1)
>
> !$omp teams distribute parallel do simd default(none) lastprivate(d1)
>
> do d1 = 0, 31
> end do
> !$omp end target
>
> if (d1 /= 32) stop 3
> end program
> ...
Corresponding dumps.
[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
--- Comment #2 from Marek Polacek ---
// PR c++/97034
namespace N {
template struct S {
template S(T, U);
};
} // namespace N
template struct E {
template struct G { T t; };
void fn() { G{N::S{'a', 1}}; }
};
[Bug target/96139] Vector element extract mistypes long long int down to long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 --- Comment #11 from CVS Commits --- The releases/gcc-8 branch has been updated by Will Schmidt : https://gcc.gnu.org/g:74c624523bdbe4329c7cb77bff222ac695e36c95 commit r8-10453-g74c624523bdbe4329c7cb77bff222ac695e36c95 Author: Will Schmidt Date: Wed Sep 16 11:21:04 2020 -0500 [PATCH, rs6000] Fix vector long long subtype (PR96139) Hi, This corrects an issue with the powerpc vector long long subtypes. As reported by SjMunroe, when building some code with -Wall, and attempting to print an element of a "long long vector" with a long long printf format string, we will report an error because the vector sub-type was improperly defined as int. When defining a V2DI_type_node we use a TARGET_POWERPC64 ternary to define the V2DI_type_node with "vector long" or "vector long long". We also need to specify the proper sub-type when we define the type. Due to some file renames, This is a backport and rework of both [PATCH, rs6000] Fix vector long long subtype (PR96139) and [PATCH, rs6000] Testsuite fixup pr96139 tests PR target/96139 gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_init_builtin): Update V2DI_type_node and unsigned_V2DI_type_node definitions. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr96139-a.c: New test. * gcc.target/powerpc/pr96139-b.c: New test. * gcc.target/powerpc/pr96139-c.c: New test.
[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96497 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug analyzer/97072] New: -Wanalyzer-malloc-leak false positive when writing through some pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97072
Bug ID: 97072
Summary: -Wanalyzer-malloc-leak false positive when writing
through some pointers
Product: gcc
Version: 11.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: ---
Initially seen when writing through an unknown_svalue pointer; this reproducer
captures similar behavior, albeit with a conjured_svalue pointer:
#include
void unknown_fn_1 (void *);
void test_1 (int co, int y)
{
void *p = malloc (1024);
void **q;
unknown_fn_1 (&q);
*q = p;
}
t.c: In function ‘test_1’:
t.c:11:1: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
11 | }
| ^
‘test_1’: events 1-2
|
|7 | void *p = malloc (1024);
| | ^
| | |
| | (1) allocated here
|..
| 11 | }
| | ~
| | |
| | (2) ‘p’ leaks here; was allocated at (1)
|
https://godbolt.org/z/WcMWda
The leak warning is a false positive, as p was written to *q.
[Bug c/97073] New: Miscompilation with -m32 -O1 -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073 Bug ID: 97073 Summary: Miscompilation with -m32 -O1 -march=i686 Product: gcc Version: 8.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sirl at gcc dot gnu.org Target Milestone: --- Created attachment 49229 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49229&action=edit Testcase demonstrating the problem. Hi, the attached simple testcase aborts when compiled with every version since gcc-7 (last tested r11-3232). Compiled with gcc-6.3.1 the testcase doesn't abort. Also adding either -fno-tree-ter or -msse2 prevents the abort.
[Bug libstdc++/96958] Long Double in Hash Table policy forces soft-float calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958 Ryan Houdek changed: What|Removed |Added CC||houdek.r...@fex-emu.org --- Comment #4 from Ryan Houdek --- Hello. Original creator of this fork here. It would be nice to at least remove the long double requirement here, I personally don't have much stock in the internal implementation details other than that. I believe other STL compliant hashable implementations end up doing something using integers for their bucket calculations. So I guess it isn't strictly necessary that it needs to even be double there. In my particular case the long double implementation falls down a particularly slow soft float path for me, so this has real performance implications. More so than just the regular AArch64 soft float path. Looking forward to this getting rectified.
[Bug analyzer/97074] New: -Wanalyzer-malloc-leak false positive when merging states
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97074
Bug ID: 97074
Summary: -Wanalyzer-malloc-leak false positive when merging
states
Product: gcc
Version: 11.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: ---
https://godbolt.org/z/5P3T8E
#include
void *x, *y;
void test_1 (int flag)
{
void *p = malloc (1024);
if (flag)
x = p;
else
y = p;
__analyzer_dump ();
}
Has this false leak report:
t.c:13:1: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
13 | }
| ^
‘test_1’: events 1-2
|
|7 | void *p = malloc (1024);
| | ^
| | |
| | (1) allocated here
|..
| 13 | }
| | ~
| | |
| | (2) ‘p’ leaks here; was allocated at (1)
|
__analyzer_dump shows that state merging leads to a merger of the x and y
values to unknown at the join-point:
rmodel:
stack depth: 1
frame (index 0): frame: ‘test_1’@1
clusters within ::
cluster for: x: UNKNOWN(void *)
cluster for: y: UNKNOWN(void *)
clusters within frame: ‘test_1’@1
cluster for: p_4: &HEAP_ALLOCATED_REGION(8)
m_called_unknown_fn: FALSE
constraint_manager:
equiv classes:
constraints:
malloc:
global: start
0x3d10590: &HEAP_ALLOCATED_REGION(8): unchecked (malloc) (‘p_4’)
[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||segher at gcc dot gnu.org Last reconfirmed||2020-09-16 --- Comment #6 from Segher Boessenkool --- Confirmed. Maaybe cse2 should do this?
[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
--- Comment #3 from Marek Polacek ---
The same ICE can be triggered with
template
struct E {
template
struct G {
T t;
G(T) { }
};
void fn() { G{1}; }
};
which started with r269093.
[Bug tree-optimization/97075] New: [11 regression] powerpc64 vector tests fails after r11-3230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97075 Bug ID: 97075 Summary: [11 regression] powerpc64 vector tests fails after r11-3230 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:052204fac580b21c967e57e6285d99a9828b8fac, r11-3230 FAIL: gcc.target/powerpc/p9-vec-length-epil-7.c scan-assembler-times \\mstxvl\\M 10 FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-not \\mlxvx\\M FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-not \\mstxvx\\M FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-times \\mlxvl\\M 16 FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-times \\mstxvl\\M 16 For the second test case here is a diff of the assembler: seurer@makalu-lp1:~/gcc/git/build/gcc-test$ diff p9-vec-length-epil-7.s.r11-3229 p9-vec-length-epil-7.s.r11-3230 322,323c322,323 < li 6,28 < addis 7,2,.LC8@toc@ha --- > li 7,28 > addis 8,2,.LC8@toc@ha 325d324 < addis 10,2,.LANCHOR0@toc@ha 327,330c326,328 < li 8,0 < mtctr 6 < addi 7,7,.LC8@toc@l < addi 10,10,.LANCHOR0@toc@l --- > li 10,0 > mtctr 7 > addi 8,8,.LC8@toc@l 333,335c331,333 < lxv 32,0(7) < addis 7,2,.LANCHOR0+904@toc@ha < std 8,.LANCHOR0+904@toc@l(7) --- > lxv 32,0(8) > addis 8,2,.LANCHOR0+904@toc@ha > std 10,.LANCHOR0+904@toc@l(8) 343,349c341,343 < addis 7,2,.LC9@toc@ha < li 8,8 < addi 9,10,1360 < addi 7,7,.LC9@toc@l < sldi 10,8,56 < lxv 0,0(7) < stxvl 0,9,10 --- > li 9,57 > addis 10,2,.LANCHOR0+1360@toc@ha > std 9,.LANCHOR0+1360@toc@l(10) 368,369c362,363 < li 6,28 < addis 7,2,.LC8@toc@ha --- > li 7,28 > addis 8,2,.LC8@toc@ha 371d364 < addis 10,2,.LANCHOR0@toc@ha 373,376c366,368 < li 8,0 < mtctr 6 < addi 7,7,.LC8@toc@l < addi 10,10,.LANCHOR0@toc@l --- > li 10,0 > mtctr 7 > addi 8,8,.LC8@toc@l 379,381c371,373 < lxv 32,0(7) < addis 7,2,.LANCHOR0+1416@toc@ha < std 8,.LANCHOR0+1416@toc@l(7) --- > lxv 32,0(8) > addis 8,2,.LANCHOR0+1416@toc@ha > std 10,.LANCHOR0+1416@toc@l(8) 389,395c381,383 < addis 7,2,.LC9@toc@ha < li 8,8 < addi 9,10,1872 < addi 7,7,.LC9@toc@l < sldi 10,8,56 < lxv 0,0(7) < stxvl 0,9,10 --- > li 9,57 > addis 10,2,.LANCHOR0+1872@toc@ha > std 9,.LANCHOR0+1872@toc@l(10) 414,415c402,403 < addis 6,2,.LC10@toc@ha < addis 7,2,.LC11@toc@ha --- > addis 6,2,.LC9@toc@ha > addis 7,2,.LC10@toc@ha 421,422c409,410 < addi 6,6,.LC10@toc@l < addi 7,7,.LC11@toc@l --- > addi 6,6,.LC9@toc@l > addi 7,7,.LC10@toc@l 441c429 < addis 7,2,.LC12@toc@ha --- > addis 7,2,.LC11@toc@ha 444c432 < addi 7,7,.LC12@toc@l --- > addi 7,7,.LC11@toc@l 466,469c454,456 < addis 7,2,.LC13@toc@ha < li 6,28 < addis 8,2,.LC14@toc@ha < addis 10,2,.LANCHOR0@toc@ha --- > addis 8,2,.LC12@toc@ha > li 7,28 > addis 10,2,.LC13@toc@ha 472,475c459,461 < addi 7,7,.LC13@toc@l < mtctr 6 < addi 8,8,.LC14@toc@l < addi 10,10,.LANCHOR0@toc@l --- > addi 8,8,.LC12@toc@l > mtctr 7 > addi 10,10,.LC13@toc@l 477,480c463,466 < lxv 0,0(7) < lxv 11,0(8) < addis 8,2,.LANCHOR0+2184@toc@ha < stfd 12,.LANCHOR0+2184@toc@l(8) --- > lxv 0,0(8) > lxv 11,0(10) > addis 10,2,.LANCHOR0+2184@toc@ha > stfd 12,.LANCHOR0+2184@toc@l(10) 488,494c474,477 < addis 7,2,.LC15@toc@ha < li 8,8 < addi 9,10,2640 < addi 7,7,.LC15@toc@l < sldi 10,8,56 < lxv 0,0(7) < stxvl 0,9,10 --- > addis 9,2,.LC14@toc@ha > lfd 0,.LC14@toc@l(9) > addis 9,2,.LANCHOR0+2640@toc@ha > stfd 0,.LANCHOR0+2640@toc@l(9)
[Bug other/97076] New: clang-format file does not work for some C++11 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97076 Bug ID: 97076 Summary: clang-format file does not work for some C++11 code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dmjpp at hotmail dot com Target Milestone: --- This is not a bug in GCC, but in the supporting files in contrib. The clang-format file at the end has Standard: Cpp03. See https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/clang-format;h=7a4e96f64ca64a332ca5f945f08425c3a3e045c6;hb=HEAD#l150 I was writing a libstdc++ patch where I used the C++11 feature Unicode string literals. auto x = u"abc"; The clang format adds a space between the u and the quotation marks, making the file invalid C++. auto x = u "abc"; The fix is to change the standard to auto: Standard: Auto
[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
--- Comment #4 from Marek Polacek ---
Another, valid, where C++20 aggregate CTAD should work:
template
struct E {
template
struct G {
T t;
};
void fn() { G{1}; }
};
void
g () {
E e;
e.fn ();
}
[Bug sanitizer/94325] [8/9 Regression] UBSAN: "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:175f052446556d32e887e1658a5a92c3c2f3a6f5 commit r9-8875-g175f052446556d32e887e1658a5a92c3c2f3a6f5 Author: Jakub Jelinek Date: Wed Apr 8 15:30:16 2020 +0200 c++: Further fix for -fsanitize=vptr [PR94325] For -fsanitize=vptr, we insert a NULL store into the vptr instead of just adding a CLOBBER of this. build_clobber_this makes the CLOBBER conditional on in_charge (implicit) parameter whenever CLASSTYPE_VBASECLASSES, but when adding this conditionalization to the -fsanitize=vptr code in PR87095, I wanted it to catch some more cases when the class has CLASSTYPE_VBASECLASSES, but the vptr is still not shared with something else, otherwise the sanitization would be less effective. The following testcase shows that the chosen test that CLASSTYPE_PRIMARY_BINFO is non-NULL and has BINFO_VIRTUAL_P set wasn't sufficient, the D class has still sizeof(D) == sizeof(void*) and thus contains just a single vptr, but while in B::~B() this results in the vptr not being cleared, in C::~C() this condition isn't true, as CLASSTYPE_PRIMARY_BINFO in that case is B and is not BINFO_VIRTUAL_P, so it clears the vptr, but the D::~D() dtor after invoking C::~C() invokes A::~A() with an already cleared vptr, which is then reported. The following patch is just a shot in the dark, keep looking through CLASSTYPE_PRIMARY_BINFO until we find BINFO_VIRTUAL_P, but it works on the existing testcase as well as this new one. 2020-04-08 Jakub Jelinek PR c++/94325 * decl.c (begin_destructor_body): For CLASSTYPE_VBASECLASSES class dtors, if CLASSTYPE_PRIMARY_BINFO is non-NULL, but not BINFO_VIRTUAL_P, look at CLASSTYPE_PRIMARY_BINFO of its BINFO_TYPE if it is not BINFO_VIRTUAL_P, and so on. * g++.dg/ubsan/vptr-15.C: New test. (cherry picked from commit 4cf6b06cb5b02c053738e2975e3b7a4b3c577401)
[Bug target/94438] [8/9 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vbmi -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94438 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cb09410d3c61d325c64b17eabe9dfd1609cec1a6 commit r9-8876-gcb09410d3c61d325c64b17eabe9dfd1609cec1a6 Author: Jakub Jelinek Date: Wed Apr 8 18:24:12 2020 +0200 i386: Don't use AVX512F integral masks for V*TImode [PR94438] The ix86_get_mask_mode hook uses int mask for 512-bit vectors or 128/256-bit vectors with AVX512VL (that is correct), and only for V*[SD][IF]mode if not AVX512BW (also correct), but with AVX512BW it would stop checking the elem_size altogether and pretend the hw has masking support for V*TImode etc., which it doesn't. That can lead to various ICEs later on. 2020-04-08 Jakub Jelinek PR target/94438 * config/i386/i386.c (ix86_get_mask_mode): Only use int mask for elem_size 1, 2, 4 and 8. * gcc.target/i386/avx512bw-pr94438.c: New test. * gcc.target/i386/avx512vlbw-pr94438.c: New test. (cherry picked from commit 8bf5faa9c463f0d53ffe835ba03d4502edfb959d)
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #26 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:489c62beef150f870d1755d3772bd2d0ce7344b4 commit r9-8878-g489c62beef150f870d1755d3772bd2d0ce7344b4 Author: Gustavo Romero Date: Wed Apr 15 15:14:45 2020 +0200 selftest: Work around GCC 4.2 PR33916 bug by optimizing the ctor [PR89494] GCC 4.2 due to PR33916 miscompiles temp_dump_context ctor, because it doesn't zero initialize the whole dump_context temporary on which it runs the static get method and during destruction of the temporary an uninitialized pointer is deleted. More recent GCC versions properly zero initialize it and ideally optimize away the construction/destruction of the temporary, as it isn't used for anything, but there is no reason to create the temporary, static member functions can be called without an associated object. 2020-04-15 Gustavo Romero PR bootstrap/89494 * dumpfile.c (selftest::temp_dump_context::temp_dump_context): Don't construct a dump_context temporary to call static method. (cherry picked from commit c00568f376078129196740d83946d54dc5437401)
[Bug tree-optimization/94524] [8/9 Regression] wrong code with vector modulo operation since r0-117580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94524 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:780b2ab071391495690141c61604370d6cf7af49 commit r9-8877-g780b2ab071391495690141c61604370d6cf7af49 Author: Jakub Jelinek Date: Wed Apr 8 21:22:05 2020 +0200 vect: Fix up lowering of TRUNC_MOD_EXPR by negative constant [PR94524] The first testcase below is miscompiled, because for the division part of the lowering we canonicalize negative divisors to their absolute value (similarly how expmed.c canonicalizes it), but when multiplying the division result back by the VECTOR_CST, we use the original constant, which can contain negative divisors. Fixed by computing ABS_EXPR of the VECTOR_CST. Unfortunately, fold-const.c doesn't support const_unop (ABS_EXPR, VECTOR_CST) and I think it is too late in GCC 10 cycle to add it now. Furthermore, while modulo by most negative constant happens to return the right value, it does that only by invoking UB in the IL, because we then expand division by that 1U+INT_MAX and say for INT_MIN % INT_MIN compute the division as -1, and then multiply by INT_MIN, which is signed integer overflow. We in theory could do the computation in unsigned vector types instead, but is it worth bothering. People that are doing % INT_MIN are either testing for standard conformance, or doing something wrong. So, I've also added punting on % INT_MIN, both in vect lowering and vect pattern recognition (we punt already for / INT_MIN). 2020-04-08 Jakub Jelinek PR tree-optimization/94524 * tree-vect-generic.c (expand_vector_divmod): If any elt of op1 is negative for signed TRUNC_MOD_EXPR, multiply with absolute value of op1 rather than op1 itself at the end. Punt for signed modulo by most negative constant. * tree-vect-patterns.c (vect_recog_divmod_pattern): Punt for signed modulo by most negative constant. * gcc.c-torture/execute/pr94524-1.c: New test. * gcc.c-torture/execute/pr94524-2.c: New test. (cherry picked from commit f52eb4f988992d393c69ee4ab76f236dced80e36)
[Bug rtl-optimization/94618] [8/9 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dea597314f4503228e23e887ddbb773cbf197093 commit r9-8881-gdea597314f4503228e23e887ddbb773cbf197093 Author: Jakub Jelinek Date: Fri Apr 17 10:33:27 2020 +0200 Fix -fcompare-debug issue in delete_insn_and_edges [PR94618] delete_insn_and_edges calls purge_dead_edges whenever deleting the last insn in a bb, whatever it is. If it called it only for mandatory last insns in the basic block (that may not be followed by DEBUG_INSNs, dunno if that is control_flow_insn_p or something more complex), that wouldn't be a problem, but as it calls it on any last insn and can actually do something in the bb, if such an insn is followed by one more more DEBUG_INSNs and nothing else in the same bb, we don't call purge_dead_edges with -g and do call it with -g0. On the testcase, there are two reg-to-reg moves with REG_EH_REGION notes (previously memory accesses but simplified and yet not optimized), and the second is followed by DEBUG_INSNs; the second move is delete_insn_and_edges and after removing it, for -g0 purge_dead_edges removes the REG_EH_REGION from the now last insn in the bb (the first reg-to-reg move), while for -g it isn't called and things diverge from that quickly on. Fixed by calling purdge_dead_edges even if we remove the last real insn followed only by DEBUG_INSNs in the same bb. 2020-04-17 Jakub Jelinek PR rtl-optimization/94618 * cfgrtl.c (delete_insn_and_edges): Set purge not just when insn is the BB_END of its block, but also when it is only followed by DEBUG_INSNs in its block. * g++.dg/opt/pr94618.C: New test. (cherry picked from commit c41884a09206be0e21cad7eea71b9754daa969d4)
[Bug c/94641] -Wpadded -fsanitize=undefined together cause warning on main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94641 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1e4a928134e8f17bbcae99f2bac2bbce73ef6f73 commit r9-8882-g1e4a928134e8f17bbcae99f2bac2bbce73ef6f73 Author: Jakub Jelinek Date: Tue Apr 21 17:06:31 2020 +0200 ubsan: Avoid -Wpadded warnings [PR94641] -Wpadded warnings aren't really useful for the artificial types that GCC lays out for ubsan. 2020-04-21 Jakub Jelinek PR c/94641 * stor-layout.c (place_field, finalize_record_size): Don't emit -Wpadded warning on TYPE_ARTIFICIAL rli->t. * ubsan.c (ubsan_get_type_descriptor_type, ubsan_get_source_location_type, ubsan_create_data): Set TYPE_ARTIFICIAL. * asan.c (asan_global_struct): Likewise. * c-c++-common/ubsan/pr94641.c: New test. (cherry picked from commit 73f8e9dca5ff891ed19001b213fd1f6ce31417e3)
[Bug c++/94571] Error: Expected comma or semicolon, comma found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94571 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a43981bb51fd0b8e68452faea6ec160cbea058e5 commit r9-8879-ga43981bb51fd0b8e68452faea6ec160cbea058e5 Author: Jakub Jelinek Date: Thu Apr 16 07:19:57 2020 +0200 c++: Fix pasto in structured binding diagnostics [PR94571] This snippet has been copied from the non-structured binding declaration parsing later in the function, and while for non-structured bindings it can be followed by comma or semicolon, structured bindings may be only followed by semicolon. Or, do we want to have a different message for the case when there is a comma (and keep this corrected one only if there is something else) that would explain better what is the bug (or add a fix-it hint)? Marek said in the PR that clang++ reports error: decomposition declaration must be the only declaration in its group There is another thing Marek noted (though, something for different spot), that diagnostic for auto x(1), [e,f] = test2; could also use a clearer wording like the above (or a fix-it hint), but the question is if we should assume [ after , as a structured binding or if we should do some tentative parsing first to figure out if it looks like a structured binding. 2020-04-16 Jakub Jelinek PR c++/94571 * parser.c (cp_parser_simple_declaration): Fix up a pasto in diagnostics. * g++.dg/cpp1z/decomp51.C: New test. (cherry picked from commit e4658c7dbbe88f742c96e5f58ee4a6d549d642ca)
[Bug c/94755] [9/10/11 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d6a341eb9170fdb21aee235142d1f09e6dc5c5cd commit r9-8886-gd6a341eb9170fdb21aee235142d1f09e6dc5c5cd Author: Jakub Jelinek Date: Mon Apr 27 16:05:03 2020 +0200 c-family: Fix ICE on __builtin_speculation_safe_value () [PR94755] When this builtin has no parameters, speculation_safe_value_resolve_call returns BUILT_IN_NONE, but resolve_overloaded_builtin uselessly dereferences the first param just to return error_mark_node immediately. The following patch rearranges it so that we only read the first parameter if fncode is not BUILT_IN_NONE. 2020-04-27 Jakub Jelinek PR c/94755 * c-common.c (resolve_overloaded_builtin): Return error_mark_node for fncode == BUILT_IN_NONE before initialization of first_param. * c-c++-common/pr94755.c: New test. (cherry picked from commit 26d76be7af6db75aaab662f4e93395f4ff8acb38)
[Bug c/94705] [8/9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396 since r8-5161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:934ede34973909eb15b678f88395d83be01433e7 commit r9-8883-g934ede34973909eb15b678f88395d83be01433e7 Author: Jakub Jelinek Date: Thu Apr 23 09:54:14 2020 +0200 attribs: Don't diagnose attribute exclusions during error recovery [PR94705] On the following testcase GCC ICEs, because last_decl is error_mark_node, and diag_attr_exclusions assumes that if it is not NULL, it must be a decl. The following patch just doesn't diagnose attribute exclusions if the other decl is erroneous (and thus we've already reported errors for it). 2020-04-23 Jakub Jelinek PR c/94705 * attribs.c (decl_attribute): Don't diagnose attribute exclusions if last_decl is error_mark_node or has such a TREE_TYPE. * gcc.dg/pr94705.c: New test. (cherry picked from commit e2a71816b4949225498bec37e947293aa7f5841b)
[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1777beb6b12983b946dae4177470a319693fc0dc commit r9-8887-g1777beb6b12983b946dae4177470a319693fc0dc Author: Jakub Jelinek Date: Mon Apr 27 21:14:52 2020 +0200 x86: Fix up ix86_atomic_assign_expand_fenv [PR94780] This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONTEXT and is added to local decls. Without that, e.g. tree-nested.c ICEs on those. 2020-04-27 Jakub Jelinek PR target/94780 * config/i386/i386.c (ix86_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR for first assignment to sw_var, exceptions_var, mxcsr_orig_var and mxcsr_mod_var. * gcc.dg/pr94780.c: New test. (cherry picked from commit 9b8e9006bb35641865358e2df4f6b3ae185b239a)
[Bug tree-optimization/94809] [8/9 Regression] Different results between gcc-9 and gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:522022361984407ebc84cde22bdbd199261d0443
commit r9--g522022361984407ebc84cde22bdbd199261d0443
Author: Jakub Jelinek
Date: Tue Apr 28 11:26:56 2020 +0200
tree: Fix up TREE_SIDE_EFFECTS on internal calls [PR94809]
On the following testcase, match.pd during GENERIC folding
changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y),
but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on
the call. There is the process_call_operands function that non-internal
call creation calls and it is usable for internal calls too,
e.g. TREE_SIDE_EFFECTS is derived from checking whether the
call has side-effects (non-ECF_{CONST,PURE}; we have those for internal
calls) and from whether any of the arguments has TREE_SIDE_EFFECTS.
2020-04-28 Jakub Jelinek
PR tree-optimization/94809
* tree.c (build_call_expr_internal_loc_array): Call
process_call_operands.
* gcc.c-torture/execute/pr94809.c: New test.
(cherry picked from commit 34f6b14ff33e0c64b3a4a1a2cd871df715d69151)
[Bug target/94710] [8/9 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:15e2cca37186c848d12f4a0bb9ebcb8be32ed9de commit r9-8884-g15e2cca37186c848d12f4a0bb9ebcb8be32ed9de Author: Jakub Jelinek Date: Thu Apr 23 21:57:50 2020 +0200 Shortcut identity VEC_PERM expansion [PR94710] This PR is about the rs6000 backend emitting wrong assembly for whole vector shift by 0, and while I think it is desirable to fix the backend, I don't see a point why the expander should try to emit that, whole vector shift by 0 is identity, we can just return the operand. 2020-04-23 Jakub Jelinek PR target/94710 * optabs.c (expand_vec_perm_const): For shift_amt const0_rtx just return v2. (cherry picked from commit f51be2fb8653f81092f8158a0f0527275f86603b)
[Bug tree-optimization/94621] [9 Regression] GCC 9.2.1 segfaults when compiling file with -O3 since r9-5354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5b23b0c44692cc5e4d5e726f96497bff73094e7b commit r9-8880-g5b23b0c44692cc5e4d5e726f96497bff73094e7b Author: Jakub Jelinek Date: Fri Apr 17 09:07:49 2020 +0200 inliner: Don't ICE on NULL TYPE_DOMAIN [PR94621] When I've added the VLA tweak for OpenMP to avoid error_mark_nodes in the IL in type, I forgot that TYPE_DOMAIN could be NULL. Furthermore, as an optimization, this patch checks the hopefully cheapest condition that is very likely false most of the time (enabled only during OpenMP handling) first. 2020-04-17 Jakub Jelinek PR tree-optimization/94621 * tree-inline.c (remap_type_1): Don't dereference NULL TYPE_DOMAIN. Move id->adjust_array_error_bounds check first in the condition. * gcc.c-torture/compile/pr94621.c: New test. (cherry picked from commit c58cb6ac6891886b7aa01c440ac71a5e7cbcba97)
[Bug c++/94742] [8/9 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e9dbd80b5e62a126ccb40970f0fb233f7e0ac3a6 commit r9-8885-ge9dbd80b5e62a126ccb40970f0fb233f7e0ac3a6 Author: Jakub Jelinek Date: Sat Apr 25 00:11:35 2020 +0200 c++: Avoid -Wreturn-type warning if a template fn calls noreturn template fn [PR94742] finish_call_expr already has code to set current_function_returns_abnormally if a template calls a noreturn function, but on the following testcase it doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case we didn't check noreturn at all and just assumed it could return. 2020-04-25 Jakub Jelinek PR c++/94742 * semantics.c (finish_call_expr): When looking if all overloads are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs. * g++.dg/warn/Wreturn-type-12.C: New test. (cherry picked from commit 4ff685a8705e8ee55fa86e75afb769ffb0975aea)
[Bug target/94826] [8/9 regression] ICE in gcc.dg/pr94780.c after r10-7999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94826 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:540e1de23a70360fe9b626df8420be704d02e3a7 commit r9-8890-g540e1de23a70360fe9b626df8420be704d02e3a7 Author: Jakub Jelinek Date: Wed Apr 29 15:55:39 2020 +0200 rs6000: Fix rs6000_atomic_assign_expand_fenv [PR94826] This is the rs6000 version of the earlier committed x86, aarch64 and arm fixes, as create_tmp_var_raw is used because the C FE can call this outside of function context, we need to make sure the first references to those VAR_DECLs are through a TARGET_EXPR, so that it gets gimple_add_tmp_var marked in whatever function it gets expanded in. Without that DECL_CONTEXT is NULL and the vars aren't added as local decls of the containing function. 2020-04-29 Jakub Jelinek PR target/94826 * config/rs6000/rs6000.c (rs6000_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR for first assignment to fenv_var, fenv_clear and old_fenv variables. For fenv_addr take address of TARGET_EXPR of fenv_var with void_node initializer. Formatting fixes. (cherry picked from commit c7137fcc7cbc1f1f14f9fed75adcc6bd8f1d418c)
[Bug middle-end/95108] [9 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b78ea59edbd354fed914d0f8eb78109db7316ce8 commit r9-8899-gb78ea59edbd354fed914d0f8eb78109db7316ce8 Author: Jakub Jelinek Date: Thu May 14 09:51:05 2020 +0200 openmp: Fix placement of 2nd+ preparation statement for PHIs in simd clone lowering [PR95108] For normal stmts, preparation statements are inserted before the stmt, so if we need multiple, they are in the correct order, but for PHIs we emit them after labels in the entry successor bb, and we used to emit them in the reverse order that way. 2020-05-14 Jakub Jelinek PR middle-end/95108 * omp-simd-clone.c (struct modify_stmt_info): Add after_stmt member. (ipa_simd_modify_stmt_ops): For PHIs, only add before first stmt in entry block if info->after_stmt is NULL, otherwise add after that stmt and update it after adding each stmt. (ipa_simd_modify_function_body): Initialize info.after_stmt. * gcc.dg/gomp/pr95108.c: New test. (cherry picked from commit d0fb9ffc1b8f3b86bbdf0e915cec2136141b329b)
[Bug target/94950] [8/9 regression] ICE in gcc.dg/pr94780.c on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:79002374e81588fa1052c21f3d397cf9ad61f97d commit r9-8896-g79002374e81588fa1052c21f3d397cf9ad61f97d Author: Jakub Jelinek Date: Wed May 6 09:40:33 2020 +0200 riscv: Fix up riscv_atomic_assign_expand_fenv [PR94950] Similarly to the fixes on many other targets, riscv needs to use TARGET_EXPR to avoid having the create_tmp_var_raw temporaries without proper DECL_CONTEXT and not mentioned in local decls. 2020-05-06 Jakub Jelinek PR target/94950 * config/riscv/riscv-builtins.c (riscv_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR for first assignment to old_flags. (cherry picked from commit 5454a13add37fa6a8eedbf9d2f6bdc63a7825e2c)
[Bug rtl-optimization/94873] [8/9 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #24 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0f717ba5975ab42e1176db4cd2384f1862872519 commit r9-8895-g0f717ba5975ab42e1176db4cd2384f1862872519 Author: Jakub Jelinek Date: Wed May 6 09:31:19 2020 +0200 combine: Don't replace SET_SRC with REG_EQUAL note content if SET_SRC has side-effects [PR94873] There were some discussions about whether REG_EQUAL notes are valid on insns with a single set which contains auto-inc-dec side-effects in the SET_SRC and the majority thinks that it should be valid. So, this patch fixes the combiner to punt in that case, because otherwise the auto-inc-dec side-effects from the SET_SRC are lost. 2020-05-06 Jakub Jelinek PR rtl-optimization/94873 * combine.c (combine_instructions): Don't optimize using REG_EQUAL note if SET_SRC (set) has side-effects. * gcc.dg/pr94873.c: New test. (cherry picked from commit 8982e39b46b1e4a4b09022ddebd758b77ab73bac)
[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d01f91514f627590adc408ac9a35a7153123119 commit r9-8898-g9d01f91514f627590adc408ac9a35a7153123119 Author: Jakub Jelinek Date: Wed May 13 11:22:37 2020 +0200 Fix -fcompare-debug issue in purge_dead_edges [PR95080] The following testcase fails with -fcompare-debug, the bug used to be latent since introduction of -fcompare-debug. The loop at the start of purge_dead_edges behaves differently between -g0 and -g - if the last insn is a DEBUG_INSN, then it skips not just DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb head), while with -g0 it will not skip any NOTEs, so if we have real_insn note debug_insn // not present with -g0 then with -g it might remove useless REG_EH_REGION from real_insn, while with -g0 it will not. Yet another option would be not skipping NOTE_P in the loop; I couldn't find in history rationale for why it is done. 2020-05-13 Jakub Jelinek PR debug/95080 * cfgrtl.c (purge_dead_edges): Skip over debug and note insns even if the last insn is a note. * g++.dg/opt/pr95080.C: New test. (cherry picked from commit 18edc195442291525e04f0fa4d5ef972155117da)
[Bug target/94832] AVX512 scatter/gather macros lack parentheses when unoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ccee0511abf6e0bb679fa6b4941e5a71a6521b12
commit r9-8892-gccee0511abf6e0bb679fa6b4941e5a71a6521b12
Author: Jakub Jelinek
Date: Wed Apr 29 17:31:26 2020 +0200
x86: Fix -O0 remaining intrinsic macros [PR94832]
A few other macros seem to suffer from the same issue. What I've done was:
cat gcc/config/i386/*intrin.h | sed -e ':x /\\$/ { N; s/\\\n//g ; bx }' \
| grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]].*(' | sed 's/[
]\+/ /g' \
> /tmp/macros
and then looking for regexps:
)[a-zA-Z]
) [a-zA-Z]
[a-zA-Z][-+*/%]
[a-zA-Z] [-+*/%]
[-+*/%][a-zA-Z]
[-+*/%] [a-zA-Z]
in the resulting file.
2020-04-29 Jakub Jelinek
PR target/94832
* config/i386/avx512bwintrin.h (_mm512_alignr_epi8,
_mm512_mask_alignr_epi8, _mm512_maskz_alignr_epi8): Wrap macro
operands
used in casts into parens.
* config/i386/avx512fintrin.h (_mm512_cvt_roundps_ph,
_mm512_cvtps_ph,
_mm512_mask_cvt_roundps_ph, _mm512_mask_cvtps_ph,
_mm512_maskz_cvt_roundps_ph, _mm512_maskz_cvtps_ph,
_mm512_mask_cmp_epi64_mask, _mm512_mask_cmp_epi32_mask,
_mm512_mask_cmp_epu64_mask, _mm512_mask_cmp_epu32_mask,
_mm512_mask_cmp_round_pd_mask, _mm512_mask_cmp_round_ps_mask,
_mm512_mask_cmp_pd_mask, _mm512_mask_cmp_ps_mask): Likewise.
* config/i386/avx512vlbwintrin.h (_mm256_mask_alignr_epi8,
_mm256_maskz_alignr_epi8, _mm_mask_alignr_epi8,
_mm_maskz_alignr_epi8,
_mm256_mask_cmp_epu8_mask): Likewise.
* config/i386/avx512vlintrin.h (_mm_mask_cvtps_ph,
_mm_maskz_cvtps_ph,
_mm256_mask_cvtps_ph, _mm256_maskz_cvtps_ph): Likewise.
* config/i386/f16cintrin.h (_mm_cvtps_ph, _mm256_cvtps_ph):
Likewise.
* config/i386/shaintrin.h (_mm_sha1rnds4_epu32): Likewise.
(cherry picked from commit 0c8217b16f307c3eedce8f22354714938613f701)
[Bug target/94832] AVX512 scatter/gather macros lack parentheses when unoptimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f97bf9657cecaaf8afd14b43e5ca9be294ab870c
commit r9-8891-gf97bf9657cecaaf8afd14b43e5ca9be294ab870c
Author: Jakub Jelinek
Date: Wed Apr 29 17:30:22 2020 +0200
x86: Fix -O0 intrinsic *gather*/*scatter* macros [PR94832]
As reported in the PR, while most intrinsic -O0 macro argument uses
are properly wrapped in ()s or used in context where having a complex
expression passed as the argument doesn't pose a problem (e.g. when
macro argument use is in between commas, or between ( and comma, or
between comma and ) etc.), especially the gather/scatter macros don't do
this and if one passes to some macro e.g. x + y as argument, the
corresponding inline function would do cast on the argument, but
the macro does (int) ARG, then it is (int) x + y rather than (int) (x + y).
The following patch fixes those issues in *gather/*scatter*; additionally,
the AVX2 macros were passing incorrect mask of e.g.
(__v2df)_mm_set1_pd((double)(long long int) -1)
which is IMHO equivalent to
(__v2df){-1.0, -1.0}
when it really wants to pass __v2df vector with all bits set.
I've used what the inline functions use for those cases.
2020-04-29 Jakub Jelinek
PR target/94832
* config/i386/avx2intrin.h (_mm_mask_i32gather_pd,
_mm256_mask_i32gather_pd, _mm_mask_i64gather_pd,
_mm256_mask_i64gather_pd, _mm_mask_i32gather_ps,
_mm256_mask_i32gather_ps, _mm_mask_i64gather_ps,
_mm256_mask_i64gather_ps, _mm_i32gather_epi64,
_mm_mask_i32gather_epi64, _mm256_i32gather_epi64,
_mm256_mask_i32gather_epi64, _mm_i64gather_epi64,
_mm_mask_i64gather_epi64, _mm256_i64gather_epi64,
_mm256_mask_i64gather_epi64, _mm_i32gather_epi32,
_mm_mask_i32gather_epi32, _mm256_i32gather_epi32,
_mm256_mask_i32gather_epi32, _mm_i64gather_epi32,
_mm_mask_i64gather_epi32, _mm256_i64gather_epi32,
_mm256_mask_i64gather_epi32): Surround macro parameter uses with
parens.
(_mm_i32gather_pd, _mm256_i32gather_pd, _mm_i64gather_pd,
_mm256_i64gather_pd, _mm_i32gather_ps, _mm256_i32gather_ps,
_mm_i64gather_ps, _mm256_i64gather_ps): Likewise. Don't use
as mask vector containing -1.0 or -1.0f elts, but instead vector
with all bits set using _mm*_cmpeq_p? with zero operands.
* config/i386/avx512fintrin.h (_mm512_i32gather_ps,
_mm512_mask_i32gather_ps, _mm512_i32gather_pd,
_mm512_mask_i32gather_pd, _mm512_i64gather_ps,
_mm512_mask_i64gather_ps, _mm512_i64gather_pd,
_mm512_mask_i64gather_pd, _mm512_i32gather_epi32,
_mm512_mask_i32gather_epi32, _mm512_i32gather_epi64,
_mm512_mask_i32gather_epi64, _mm512_i64gather_epi32,
_mm512_mask_i64gather_epi32, _mm512_i64gather_epi64,
_mm512_mask_i64gather_epi64, _mm512_i32scatter_ps,
_mm512_mask_i32scatter_ps, _mm512_i32scatter_pd,
_mm512_mask_i32scatter_pd, _mm512_i64scatter_ps,
_mm512_mask_i64scatter_ps, _mm512_i64scatter_pd,
_mm512_mask_i64scatter_pd, _mm512_i32scatter_epi32,
_mm512_mask_i32scatter_epi32, _mm512_i32scatter_epi64,
_mm512_mask_i32scatter_epi64, _mm512_i64scatter_epi32,
_mm512_mask_i64scatter_epi32, _mm512_i64scatter_epi64,
_mm512_mask_i64scatter_epi64): Surround macro parameter uses with
parens.
* config/i386/avx512pfintrin.h (_mm512_prefetch_i32gather_pd,
_mm512_prefetch_i32gather_ps, _mm512_mask_prefetch_i32gather_pd,
_mm512_mask_prefetch_i32gather_ps, _mm512_prefetch_i64gather_pd,
_mm512_prefetch_i64gather_ps, _mm512_mask_prefetch_i64gather_pd,
_mm512_mask_prefetch_i64gather_ps, _mm512_prefetch_i32scatter_pd,
_mm512_prefetch_i32scatter_ps, _mm512_mask_prefetch_i32scatter_pd,
_mm512_mask_prefetch_i32scatter_ps, _mm512_prefetch_i64scatter_pd,
_mm512_prefetch_i64scatter_ps, _mm512_mask_prefetch_i64scatter_pd,
_mm512_mask_prefetch_i64scatter_ps): Likewise.
* config/i386/avx512vlintrin.h (_mm256_mmask_i32gather_ps,
_mm_mmask_i32gather_ps, _mm256_mmask_i32gather_pd,
_mm_mmask_i32gather_pd, _mm256_mmask_i64gather_ps,
_mm_mmask_i64gather_ps, _mm256_mmask_i64gather_pd,
_mm_mmask_i64gather_pd, _mm256_mmask_i32gather_epi32,
_mm_mmask_i32gather_epi32, _mm256_mmask_i32gather_epi64,
_mm_mmask_i32gather_epi64, _mm256_mmask_i64gather_epi32,
_mm_mmask_i64gather_epi32, _mm256_mmask_i64gather_epi64,
_mm_mmask_i64gather_epi64, _mm256_i32scatter_ps,
[Bug target/94820] [8/9 Regression] pr94780.c fails with ICE on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94820 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:029d813ddf3595bfc93bfb4afad645dd033d21bf commit r9-8889-g029d813ddf3595bfc93bfb4afad645dd033d21bf Author: Haijian Zhang Date: Wed Apr 29 10:23:11 2020 +0200 pr94780.c fails with ICE on aarch64 [PR94820] This is a simple fix for pr94820. The PR was only fixed on i386, the same error was also reported on aarch64. This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONTEXT and is added to local decls. Without that, e.g. tree-nested.c ICEs on those. 2020-04-29 Haijian Zhang PR target/94820 * config/aarch64/aarch64-builtins.c (aarch64_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR for first assignment to fenv_cr, fenv_sr and new_fenv_var. (cherry picked from commit d81bc2af7d2700888e414eb5a322ff5f5b0df0bb)
[Bug c++/94951] [8/9 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94951 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:eca1dbea010ba4c18ccec90bacbad5d8ec72c09f commit r9-8897-geca1dbea010ba4c18ccec90bacbad5d8ec72c09f Author: Jakub Jelinek Date: Wed May 6 23:38:13 2020 +0200 c++: Avoid strict_aliasing_warning on dependent types or expressions [PR94951] The following testcase gets a bogus warning during build_base_path, when cp_build_indirect_ref* calls strict_aliasing_warning with a dependent expression. IMHO calling get_alias_set etc. on dependent types feels wrong to me, we should just defer the warnings in those cases until instantiation and only handle the cases where neither type nor expr are dependent. 2020-05-06 Jakub Jelinek PR c++/94951 * typeck.c (cp_strict_aliasing_warning): New function. (cp_build_indirect_ref_1, build_reinterpret_cast_1): Use it instead of strict_aliasing_warning. * g++.dg/warn/Wstrict-aliasing-bogus-tmpl.C: New test. (cherry picked from commit d82414ebcf7716ea24688510594a2c464a105908)
[Bug c++/95328] structured binding of template type inside template function is reported as "incomplete class type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95328 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8efa945b308307fd9b0313705f5826a8499de405 commit r9-8900-g8efa945b308307fd9b0313705f5826a8499de405 Author: Jakub Jelinek Date: Thu May 28 23:40:54 2020 +0200 c++: Try to complete decomp types [PR95328] Two years ago Paolo has added the else if (processing_template_decl && !COMPLETE_TYPE_P (type)) pedwarn (...); lines into cp_finish_decomp. For type dependent decl we punt much earlier, but even for types which aren't type dependent COMPLETE_TYPE_P might be false as this testcase shows, so this patch tries to complete_type first (the reason for writing it that way is that it is then followed by another else if and if complete_type returns error_mark_node, we shouldn't report anything, as a bug should have been reported already. 2020-05-28 Jakub Jelinek PR c++/95328 * decl.c (cp_finish_decomp): Call complete_type before checking COMPLETE_TYPE_P. * g++.dg/cpp1z/decomp53.C: New test. (cherry picked from commit 3d8d5ddb539a5254c7ef83414377f4c74c7701d4)
[Bug c/94842] [8/9 Regression] internal compiler error: in gimplify_label_expr, at gimplify.c:2573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94842 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b66139a3ba159473432edabb983c62219a28590d commit r9-8894-gb66139a3ba159473432edabb983c62219a28590d Author: Jakub Jelinek Date: Thu Apr 30 21:48:30 2020 +0200 c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842] If there are _Atomic side-effects in the parameter declarations of non-nested function, when they are parsed, current_function_decl is NULL, the create_artificial_label created labels during build_atomic* are then adjusted by store_parm_decls through set_labels_context_r callback. Unfortunately, if such thing happens in nested function parameter declarations, while those decls are parsed current_function_decl is the parent function (and am not sure it is a good idea to temporarily clear it, some code perhaps should be aware it is in a nested function, or it can refer to variables from the parent function etc.) and that means store_param_decls through set_labels_context_r doesn't adjust anything. As those labels are emitted in the nested function body rather than in the parent, I think it is ok to override the context in those cases. 2020-04-30 Jakub Jelinek PR c/94842 * c-decl.c (set_labels_context_r): In addition to context-less LABEL_DECLs adjust also LABEL_DECLs with context equal to parent function if any. (store_parm_decls): Adjust comment. * gcc.dg/pr94842.c: New test. (cherry picked from commit 61fb8963c22d91152a9c46a3512307bef3b3d7f7)
[Bug middle-end/95903] gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a1eb6e41832816b671d3b945014f7e8255167470
commit r9-8902-ga1eb6e41832816b671d3b945014f7e8255167470
Author: Jakub Jelinek
Date: Sat Jun 27 12:38:23 2020 +0200
c-family: Use TYPE_OVERFLOW_UNDEFINED instead of !TYPE_UNSIGNED in
pointer_sum [PR95903]
For lp64 targets and int off ... ptr[off + 1]
is lowered in pointer_sum to *(ptr + ((sizetype) off + (sizetype) 1)).
That is fine when signed integer wrapping is undefined (and is not done
already if off has unsigned type), but changes behavior for -fwrapv, where
overflow is well defined. Runtime test could be:
int
main ()
{
char *p = __builtin_malloc (0x1UL);
if (!p) return 0;
char *q = p + 0x8000UL;
int o = __INT_MAX__;
q[o + 1] = 1;
if (q[-__INT_MAX__ - 1] != 1) __builtin_abort ();
return 0;
}
with -fwrapv or so, not included in the testsuite because it requires 4GB
allocation (with some other test it would be enough to have something
slightly above 2GB, but still...).
2020-06-27 Jakub Jelinek
PR middle-end/95903
gcc/c-family/
* c-common.c (pointer_int_sum): Use TYPE_OVERFLOW_UNDEFINED instead
of
!TYPE_UNSIGNED check to see if we can apply distributive law and
handle
smaller precision intop operands separately.
gcc/testsuite/
* c-c++-common/pr95903.c: New test.
(cherry picked from commit 37995960984ea346dd9d168d332cd6f7adf0)
[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95810 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6ff6c02695c9b6ae6e840422080f6d10449577b8 commit r9-8901-g6ff6c02695c9b6ae6e840422080f6d10449577b8 Author: Jakub Jelinek Date: Wed Jun 24 10:40:02 2020 +0200 fold-const: Fix A <= 0 ? A : -A folding [PR95810] We folded A <= 0 ? A : -A into -ABS (A), which is for signed integral types incorrect - can invoke on INT_MIN UB twice, once on ABS and once on its negation. The following patch fixes it by instead folding it to (type)-ABSU (A). 2020-06-24 Jakub Jelinek PR middle-end/95810 * fold-const.c (fold_cond_expr_with_comparison): Optimize A <= 0 ? A : -A into (type)-absu(A) rather than -abs(A). * gcc.dg/ubsan/pr95810.c: New test. (cherry picked from commit 01e10b0ee77e82cb331414c569e02dc7a2c4999e)
[Bug middle-end/96426] __builtin_convertvector ICE without lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96426 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3f804f63cde54ff94f35abd00953b050a4c861c7 commit r9-8905-g3f804f63cde54ff94f35abd00953b050a4c861c7 Author: Jakub Jelinek Date: Tue Aug 4 11:33:18 2020 +0200 veclower: Don't ICE on .VEC_CONVERT calls with no lhs [PR96426] .VEC_CONVERT is a const internal call, so normally if the lhs is not used, we'd DCE it far before getting to veclower, but with -O0 (or perhaps -fno-tree-dce and some other -fno-* options) it can happen. But as the internal fn needs the lhs to know the type to which the conversion is done (and I think that is a reasonable representation, having some magic another argument and having to create constants with that type looks overkill to me), we just should DCE those calls ourselves. During veclower, we can't really remove insns, as the callers would be upset, so this just replaces it with a GIMPLE_NOP. 2020-08-04 Jakub Jelinek PR middle-end/96426 * tree-vect-generic.c (expand_vector_conversion): Replace .VEC_CONVERT call with GIMPLE_NOP if there is no lhs. * gcc.c-torture/compile/pr96426.c: New test. (cherry picked from commit 95f5a3258dd8a9584f2b10304f79441ef2d4c64c)
[Bug c/96545] ICE in get_atomic_generic_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96545 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:67627293b4fe2b230c6c32484752adb49f713315 commit r9-8908-g67627293b4fe2b230c6c32484752adb49f713315 Author: Jakub Jelinek Date: Tue Aug 11 16:46:49 2020 +0200 c-family: Fix ICE in get_atomic_generic_size [PR96545] As the testcase shows, we would ICE if the type of the first argument of various atomic builtins was pointer to (non-void) incomplete type, we would assume that TYPE_SIZE_UNIT must be non-NULL. This patch diagnoses it instead. And also changes the TREE_CODE != INTEGER_CST check to !tree_fits_uhwi_p, as we use tree_to_uhwi after this and at least in theory the int could be too large and not fit. 2020-08-11 Jakub Jelinek PR c/96545 * c-common.c (get_atomic_generic_size): Require that first argument's type points to a complete type and use tree_fits_uhwi_p instead of just INTEGER_CST TREE_CODE check for the TYPE_SIZE_UNIT. * c-c++-common/pr96545.c: New test. (cherry picked from commit 7840b4dc05539cf5575b3e9ff57ff5f6c3da2cae)
[Bug c/96571] Bad "set but not used" warning with _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96571 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d2472e513c6490b6e2832b07d08731df26e6dc06 commit r9-8909-gd2472e513c6490b6e2832b07d08731df26e6dc06 Author: Jakub Jelinek Date: Tue Aug 18 07:51:58 2020 +0200 c: Fix -Wunused-but-set-* warning with _Generic [PR96571] The following testcase shows various problems with -Wunused-but-set* warnings and _Generic construct. I think it is best to treat the selector and the ignored expressions as (potentially) read, because when they are parsed, the vars in there are already marked as TREE_USED. 2020-08-18 Jakub Jelinek PR c/96571 * c-parser.c (c_parser_generic_selection): Change match_found from bool to int, holding index of the match. Call mark_exp_read on the selector expression and on expressions other than the selected one. * gcc.dg/Wunused-var-4.c: New test. (cherry picked from commit 6d42cbe5ad7a7b46437f2576c9920e44dc14b386)
[Bug fortran/93553] ICE in scan_omp_1_op, at omp-low.c:3485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cdc1ed0ceaf7e520164c262358ea6bfe89ff027c commit r9-8907-gcdc1ed0ceaf7e520164c262358ea6bfe89ff027c Author: Jakub Jelinek Date: Sat Aug 8 11:10:30 2020 +0200 openmp: Handle clauses with gimple sequences in convert_nonlocal_omp_clauses properly If the walk_body on the various sequences of reduction, lastprivate and/or linear clauses needs to create a temporary variable, we should declare that variable in that sequence rather than outside, where it would need to be privatized inside of the construct. 2020-08-08 Jakub Jelinek PR fortran/93553 * tree-nested.c (convert_nonlocal_omp_clauses): For OMP_CLAUSE_REDUCTION, OMP_CLAUSE_LASTPRIVATE and OMP_CLAUSE_LINEAR save info->new_local_var_chain around walks of the clause gimple sequences and declare_vars if needed into the sequence. 2020-08-08 Tobias Burnus PR fortran/93553 * testsuite/libgomp.fortran/pr93553.f90: New test. (cherry picked from commit 676b5525e8333005bdc1c596ed086f1da27a450f)
[Bug debug/96729] [11 Regression] slow compile with `-g -O3` since r11-39-gf9e1ea10e657af9f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96729
--- Comment #10 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ace10c37de7c2f9f2d419337dc1f173c01f7ec7d
commit r9-8911-gace10c37de7c2f9f2d419337dc1f173c01f7ec7d
Author: Jakub Jelinek
Date: Wed Aug 26 10:30:15 2020 +0200
dwarf2out: Fix up dwarf2out_next_real_insn caching [PR96729]
The addition of NOTE_INSN_BEGIN_STMT and NOTE_INSN_INLINE_ENTRY notes
reintroduced quadratic behavior into dwarf2out_var_location.
This function needs to know the next real instruction to which the var
location note applies, but the way final_scan_insn is called outside of
final.c main loop doesn't make it easy to look up the next real insn in
there (and for non-dwarf it is even useless). Usually next real insn is
only a few notes away, but we can have hundreds of thousands of consecutive
notes only followed by a real insn. dwarf2out_var_location to avoid the
quadratic behavior contains a cache, it remembers the next note and when it
is called again on that loc_note, it can use the previously computed
dwarf2out_next_real_insn result, rather than walking the insn chain once
again. But, for NOTE_INSN_{BEGIN_STMT,INLINE_ENTRY} dwarf2out_var_location
is not called while the code puts into the cache those notes, which means
if
we have e.g. in the worst case NOTE_INSN_VAR_LOCATION and
NOTE_INSN_BEGIN_STMT notes alternating, the cache is not really used.
The following patch fixes it by looking up the next NOTE_INSN_VAR_LOCATION
if any. While the lookup could be perhaps done together with looking for
the next real insn once (e.g. in dwarf2out_next_real_insn or its copy),
there are other dwarf2out_next_real_insn callers which don't need/want that
behavior and if there are more than two NOTE_INSN_VAR_LOCATION notes
followed by the same real insn, we need to do that "find next
NOTE_INSN_VAR_LOCATION" walk anyway.
On the testcase from the PR this patch speeds it 2.8times, from 0m0.674s
to 0m0.236s (why it takes for the reporter more than 60s is unknown).
2020-08-26 Jakub Jelinek
PR debug/96729
* dwarf2out.c (dwarf2out_next_real_insn): Adjust function comment.
(dwarf2out_var_location): Look for next_note only if next_real is
non-NULL, in that case look for the first non-deleted
NOTE_INSN_VAR_LOCATION between loc_note and next_real, if any.
(cherry picked from commit ca1afa261d03c9343dff1208325f87d9ba69ec7a)
[Bug target/96174] AVX-512 functions missing when compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:fdcb6dae610aba75e23c1fd2d31b491691e54091
commit r9-8904-gfdcb6dae610aba75e23c1fd2d31b491691e54091
Author: Jakub Jelinek
Date: Wed Jul 15 11:34:44 2020 +0200
fix _mm512_{,mask_}cmp*_p[ds]_mask at -O0 [PR96174]
The _mm512_{,mask_}cmp_p[ds]_mask and also _mm_{,mask_}cmp_s[ds]_mask
intrinsics have an argument which must have a constant passed to it
and so use an inline version only for ifdef __OPTIMIZE__ and have
a #define for -O0. But the _mm512_{,mask_}cmp*_p[ds]_mask intrinsics
don't need a constant argument, they are essentially the first
set with the constant added to them implicitly based on the comparison
name, and so there is no #define version for them (correctly).
But their inline versions are defined in between the first and s[ds]
set and so inside of ifdef __OPTIMIZE__, which means that with -O0
they aren't defined at all.
This patch fixes that by moving those after the #ifdef __OPTIMIZE #else
use #define #endif block.
2020-07-15 Jakub Jelinek
PR target/96174
* config/i386/avx512fintrin.h (_mm512_cmpeq_pd_mask,
_mm512_mask_cmpeq_pd_mask, _mm512_cmplt_pd_mask,
_mm512_mask_cmplt_pd_mask, _mm512_cmple_pd_mask,
_mm512_mask_cmple_pd_mask, _mm512_cmpunord_pd_mask,
_mm512_mask_cmpunord_pd_mask, _mm512_cmpneq_pd_mask,
_mm512_mask_cmpneq_pd_mask, _mm512_cmpnlt_pd_mask,
_mm512_mask_cmpnlt_pd_mask, _mm512_cmpnle_pd_mask,
_mm512_mask_cmpnle_pd_mask, _mm512_cmpord_pd_mask,
_mm512_mask_cmpord_pd_mask, _mm512_cmpeq_ps_mask,
_mm512_mask_cmpeq_ps_mask, _mm512_cmplt_ps_mask,
_mm512_mask_cmplt_ps_mask, _mm512_cmple_ps_mask,
_mm512_mask_cmple_ps_mask, _mm512_cmpunord_ps_mask,
_mm512_mask_cmpunord_ps_mask, _mm512_cmpneq_ps_mask,
_mm512_mask_cmpneq_ps_mask, _mm512_cmpnlt_ps_mask,
_mm512_mask_cmpnlt_ps_mask, _mm512_cmpnle_ps_mask,
_mm512_mask_cmpnle_ps_mask, _mm512_cmpord_ps_mask,
_mm512_mask_cmpord_ps_mask): Move outside of __OPTIMIZE__ guarded
section.
* gcc.target/i386/avx512f-vcmppd-3.c: New test.
* gcc.target/i386/avx512f-vcmpps-3.c: New test.
(cherry picked from commit 12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c)
[Bug middle-end/96459] OpenMP host teams reductions ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96459 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:464ed899038051f80af1df7197e561f327502107 commit r9-8906-g464ed899038051f80af1df7197e561f327502107 Author: Jakub Jelinek Date: Wed Aug 5 10:40:10 2020 +0200 openmp: Handle reduction clauses on host teams construct [PR96459] As the new testcase shows, we weren't actually performing reductions on host teams construct. And fixing that revealed a flaw in the for-14.c testcase. The problem is that the tests perform also initialization and checking around the calls to the functions with the OpenMP constructs. In that testcase, all the tests have been spawned from a teams construct but only the tested loops were distribute, which means the initialization and checking has been performed redundantly and racily in each team. Fixed by performing the initialization and checking outside of host teams and only do the calls to functions with the tested constructs inside of host teams. 2020-08-05 Jakub Jelinek PR middle-end/96459 * omp-low.c (lower_omp_taskreg): Call lower_reduction_clauses even in for host teams. * testsuite/libgomp.c/teams-3.c: New test. * testsuite/libgomp.c-c++-common/for-2.h (OMPTEAMS): Define to nothing if not defined yet. (N(test)): Use it before all N(f*) calls. * testsuite/libgomp.c-c++-common/for-14.c (DO_PRAGMA, OMPTEAMS): Define. (main): Don't call all test_* functions from within #pragma omp teams reduction(|:err), call them directly. (cherry picked from commit 916c7a201a9a1dc94f2c056a773826a26d1daca9)
[Bug tree-optimization/96722] [8/9 Regression] Clobbers on NULL since r8-1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:acd97038dba34830520ed58915d509d21348b554
commit r9-8910-gacd97038dba34830520ed58915d509d21348b554
Author: Jakub Jelinek
Date: Tue Aug 25 13:49:40 2020 +0200
gimple: Ignore *0 = {CLOBBER} in path isolation [PR96722]
Clobbers of MEM_REF with NULL address are just fancy nops, something we
just
ignore and don't emit any code for it (ditto for other clobbers), they just
mark end of life on something, so we shouldn't infer from those that there
is some UB.
2020-08-25 Jakub Jelinek
PR tree-optimization/96722
* gimple.c (infer_nonnull_range): Formatting fix.
(infer_nonnull_range_by_dereference): Return false for clobber
stmts.
* g++.dg/opt/pr96722.C: New test.
(cherry picked from commit a5b15fcb954ba63d58f0daa700281aba33b5f24a)
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:25542b27aa6a75ad0f7316c3767c957cce912fb7 commit r9-8912-g25542b27aa6a75ad0f7316c3767c957cce912fb7 Author: Jakub Jelinek Date: Thu Sep 3 20:11:43 2020 +0200 c++: Disable -frounding-math during manifestly constant evaluation [PR96862] As discussed in the PR, fold-const.c punts on floating point constant evaluation if the result is inexact and -frounding-math is turned on. /* Don't constant fold this floating point operation if the result may dependent upon the run-time rounding mode and flag_rounding_math is set, or if GCC's software emulation is unable to accurately represent the result. */ if ((flag_rounding_math || (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations)) && (inexact || !real_identical (&result, &value))) return NULL_TREE; Jonathan said that we should be evaluating them anyway, e.g. conceptually as if they are done with the default rounding mode before user had a chance to change that, and e.g. in C in initializers it is also ignored. In fact, fold-const.c for C initializers turns off various other options: /* Perform constant folding and related simplification of initializer expression EXPR. These behave identically to "fold_buildN" but ignore potential run-time traps and exceptions that fold must preserve. */ int saved_signaling_nans = flag_signaling_nans;\ int saved_trapping_math = flag_trapping_math;\ int saved_rounding_math = flag_rounding_math;\ int saved_trapv = flag_trapv;\ int saved_folding_initializer = folding_initializer;\ flag_signaling_nans = 0;\ flag_trapping_math = 0;\ flag_rounding_math = 0;\ flag_trapv = 0;\ folding_initializer = 1; flag_signaling_nans = saved_signaling_nans;\ flag_trapping_math = saved_trapping_math;\ flag_rounding_math = saved_rounding_math;\ flag_trapv = saved_trapv;\ folding_initializer = saved_folding_initializer; So, shall cxx_eval_outermost_constant_expr instead turn off all those options (then warning_sentinel wouldn't be the right thing to use, but given the 8 or how many return stmts in cxx_eval_outermost_constant_expr, we'd need a RAII class for this. Not sure about the folding_initializer, that one is affecting complex multiplication and division constant evaluation somehow. 2020-09-03 Jakub Jelinek PR c++/96862 * constexpr.c (cxx_eval_outermost_constant_expr): Temporarily disable flag_rounding_math during manifestly constant evaluation. * g++.dg/cpp1z/constexpr-96862.C: New test. (cherry picked from commit 6641d6d3fe79113f8d9f3ced355aea79bffda822)
[Bug c/95857] [8/9/10 Regression] Silencing an unused label warning with (void)&&label; can make gcc segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95857 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:62714a106493d0f1f22ff98c2dff2204f09cfcc0 commit r9-8903-g62714a106493d0f1f22ff98c2dff2204f09cfcc0 Author: Jakub Jelinek Date: Thu Jul 2 11:38:20 2020 +0200 tree-cfg: Fix ICE with switch stmt to unreachable opt and forced labels [PR95857] The following testcase ICEs, because during the cfg cleanup, we see: switch (i$e_11) [33.33%], case -3: [33.33%], case 0: [33.33%], case 2: [33.33%]> ... lab2: __builtin_unreachable (); where lab2 is FORCED_LABEL. The way it works, we go through the case labels and when we reach the first one that points to gimple_seq_unreachable* basic block, we remove the edge (if any) from the switch bb to the bb containing the label and bbs reachable only through that edge we've just removed. Once we do that, we must throw away all other cases that use the same label (or some other labels from the same bb we've removed the edge to and the bb). To avoid quadratic behavior, this is not done by walking all remaining cases immediately before removing, but only when processing them later. For normal labels this works, fine, if the label is in a deleted bb, it will have NULL label_to_block and we handle that case, or, if the unreachable bb has some other edge to it, only the edge will be removed and not the bb, and again, find_edge will not find the edge and we only remove the case. And if a label would be to some other block, that other block wouldn't have been removed earlier because there would be still an edge from the switch block. Now, FORCED_LABEL (and I think DECL_NONLOCAL too) break this, because those labels aren't removed, but instead moved to some surrounding basic block. So, when we later process those, when their gimple_seq_unreachable* basic block is removed, label_to_block will return some unrelated block (in the testcase the switch bb), so we decide to keep the case which doesn't seem to be unreachable, but we don't really have an edge from the switch block to the block the label got moved to. I thought first about punting in gimple_seq_unreachable* on FORCED_LABEL/DECL_NONLOCAL labels, but that might penalize even code that doesn't care, so this instead just makes sure that for FORCED_LABEL/DECL_NONLOCAL labels that are being removed (and thus moved randomly) we remember in a hash_set the fact that those labels should be treated as removed for the purpose of the optimization, and later on handle those labels that way. 2020-07-02 Jakub Jelinek PR tree-optimization/95857 * tree-cfg.c (group_case_labels_stmt): When removing an unreachable base_bb, remember all forced and non-local labels on it and later treat those as if they have NULL label_to_block. Formatting fix. Fix a comment typo. * gcc.dg/pr95857.c: New test. (cherry picked from commit 00f24f56732861d09a9716fa5b6b8a96c2289143)
[Bug tree-optimization/96295] [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96295 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:8b75204b27cb2a296ac329d48918992b4053c61e commit r11-3237-g8b75204b27cb2a296ac329d48918992b4053c61e Author: Martin Sebor Date: Wed Sep 16 13:23:31 2020 -0600 Work harder to avoid -Wuninitialized for objects of empty structs (PR middle-end/96295). Resolves: PR middle-end/96295 - -Wmaybe-uninitialized warning for range operator with reference to an empty struct gcc/ChangeLog: PR middle-end/96295 * tree-ssa-uninit.c (maybe_warn_operand): Work harder to avoid warning for objects of empty structs gcc/testsuite/ChangeLog: PR middle-end/96295 * g++.dg/warn/Wuninitialized-11.C: New test.
[Bug tree-optimization/96295] [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96295 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in r11-3237.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 96295, which changed state. Bug 96295 Summary: [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96295 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #7 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:31dd5cd6344bfbbe122fb512993b128e11236d35 commit r11-3238-g31dd5cd6344bfbbe122fb512993b128e11236d35 Author: Marek Polacek Date: Wed Sep 16 09:27:29 2020 -0400 preprocessor: Fix ICE with too long line in fmtwarn [PR96935] Here we ICE in char_span::subspan because the offset it gets is -1. It's -1 because get_substring_ranges_for_loc gets a location whose column was 0. That only happens in testcases like the attached where we're dealing with extremely long lines (at least 4065 chars it seems). This does happen in practice, though, so it's not just a theoretical problem (e.g. when building the SU2 suite). Fixed by checking that the column get_substring_ranges_for_loc gets is sane, akin to other checks in that function. gcc/ChangeLog: PR preprocessor/96935 * input.c (get_substring_ranges_for_loc): Return if start.column is less than 1. gcc/testsuite/ChangeLog: PR preprocessor/96935 * gcc.dg/format/pr96935.c: New test.
[Bug preprocessor/96935] [9/10 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 Marek Polacek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |subspan, at input.h:69 |subspan, at input.h:69 --- Comment #8 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/94102] Variadic template deduction guide issue - error: 'In instantiation of'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94102 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-16 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Fixed by r11-1571.
