[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #24 from Gejoe --- Thank you Martin for all the info. Kindly bear with me for the delayed acknowledgement.
[Bug c/100844] New: ICE with -O2: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100844
Bug ID: 100844
Summary: ICE with -O2: Segmentation fault signal terminated
program cc1
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
(Sorry about this lengthy bug report. I could not reduce it further.)
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210601 (experimental) [master revision
:54832e2f6:28daadc98094501175c9dfe4a985871fa6aa4f94] (GCC)
$ cat mutant.c
int
foo (char *p, unsigned n)
{
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n--)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n)
while (n--)
while (n--)
while (n)
while (n)
while (n)
while (n)
while (n--)
while (n--)
while (n)
while (n--)
while (n)
while (n)
while (n)
while (n)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
while (n--)
[Bug c/100843] New: ICE with -O1: in try_store_by_multiple_pieces, at builtins.c:6739
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100843
Bug ID: 100843
Summary: ICE with -O1: in try_store_by_multiple_pieces, at
builtins.c:6739
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210601 (experimental) [master revision
:54832e2f6:28daadc98094501175c9dfe4a985871fa6aa4f94] (GCC)
$ cat mutant.c
char c;
void *memset();
test_integer_conversion_memset(void *d) { memset(d, '\0', c); }
$ gcc-trunk -O1 mutant.c
mutant.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | test_integer_conversion_memset(void *d) { memset(d, '\0', c); }
| ^~
mutant.c: In function ‘test_integer_conversion_memset’:
mutant.c:3:59: warning: ‘memset’ argument 3 promotes to ‘int’ where ‘long
unsigned int’ is expected in a call to built-in function declared without
prototype [-Wbuiltin-declaration-mismatch]
3 | test_integer_conversion_memset(void *d) { memset(d, '\0', c); }
| ^
mutant.c:2:7: note: built-in ‘memset’ declared here
2 | void *memset();
| ^~
during RTL pass: expand
mutant.c:3:43: internal compiler error: in try_store_by_multiple_pieces, at
builtins.c:6739
3 | test_integer_conversion_memset(void *d) { memset(d, '\0', c); }
| ^~
0x681394 try_store_by_multiple_pieces(rtx_def*, rtx_def*, unsigned int,
unsigned long, unsigned long, rtx_def*, char, unsigned int)
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/builtins.c:6739
0xb720bd clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned
int, long, unsigned long, unsigned long, unsigned long, unsigned int)
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/expr.c:3201
0xa099a2 expand_builtin_memset_args
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/builtins.c:6969
0xa1bbfe expand_builtin_memset
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/builtins.c:6685
0xa1bbfe expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/builtins.c:10187
0xb6be8c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/expr.c:11429
0xa45f49 expand_expr
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/expr.h:301
0xa45f49 expand_call_stmt
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/cfgexpand.c:2846
0xa45f49 expand_gimple_stmt_1
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/cfgexpand.c:3850
0xa45f49 expand_gimple_stmt
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/cfgexpand.c:4014
0xa4b8a9 expand_gimple_basic_block
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/cfgexpand.c:6056
0xa4d77f execute
/tmp/tmp.4wFFqTQrHF-gcc-builder/gcc/gcc/cfgexpand.c:6782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug sanitizer/100665] [hwsanitizer] nested funtion pointer is tagged but never checked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100665 --- Comment #2 from Hongtao.liu --- (In reply to Matthew Malcomson from comment #1) > Hi there. > I believe this is how it should work (if I'm understanding & remembering > correctly). > > When creating a nested function, we make a single object on the stack that > includes all variables used in the nested function plus a trampoline. > This is called the "nonlocal frame struct" as described in gcc/tree-nested.c. > > That single object gets a single tag like all other objects in tagged memory > (trying to separate the closed-over objects from the trampoline and argument > pointers would be pretty awkward when the object is just one struct as far as > the expand code is concerned). > > That tag is checked when accessing the closed over variables (i.e. big_array > in > the example), so we definitely want to tag the object. > This sounds reasonable. > Given that, the question of whether the function pointer (i.e. the pointer to > the trampoline inside that object) should be tagged when passed elsewhere > then > has a few benefits: > 1) In this case there is no check performed, but there may be checks > performed >if e.g. this function pointer gets cast to an integer pointer and some > code >elsewhere attempts to read that integer. I'm not sure there're cases where code pointers are casted to integer pointers. But consider the above comment, I agree that tag is needed for the object. BTW, I bring this up because I'm working on supporting hwsan with Intel LAM, but unlike TBI, Intel LAM only supports tagging of data pointer. So it looks like we need to mask off code pointers for indirect call or jmp in compiler-rt.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 98365, which changed state. Bug 98365 Summary: Miss vectoization for signed char ifcvt https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98365 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug other/98375] [meta bug] GCC 12 pending patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375 Bug 98375 depends on bug 98365, which changed state. Bug 98365 Summary: Miss vectoization for signed char ifcvt https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98365 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/98365] Miss vectoization for signed char ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98365 Hongtao.liu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Hongtao.liu --- Fixed in GCC12.
[Bug tree-optimization/98365] Miss vectoization for signed char ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98365 --- Comment #7 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:28daadc98094501175c9dfe4a985871fa6aa4f94 commit r12-1138-g28daadc98094501175c9dfe4a985871fa6aa4f94 Author: liuhongt Date: Wed Jan 6 16:33:27 2021 +0800 Extend is_cond_scalar_reduction to handle nop_expr after/before scalar reduction.[PR98365] gcc/ChangeLog: PR tree-optimization/98365 * tree-if-conv.c (strip_nop_cond_scalar_reduction): New function. (is_cond_scalar_reduction): Handle nop_expr in cond scalar reduction. (convert_scalar_cond_reduction): Ditto. (predicate_scalar_phi): Ditto. gcc/testsuite/ChangeLog: PR tree-optimization/98365 * gcc.target/i386/pr98365.c: New test.
[Bug tree-optimization/100774] [12 Regression] -fcompare-debug failure (length) with -O2 -fno-tree-forwprop --param=evrp-mode=ranger-trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Macleod --- fixed.
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Andrew Macleod --- Should be Fixed.
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 Andrew Macleod changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 --- Comment #7 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:715914d3f9e4e40af58d22103c7650cdd720ef92 commit r12-1137-g715914d3f9e4e40af58d22103c7650cdd720ef92 Author: Andrew MacLeod Date: Mon May 31 12:13:50 2021 -0400 Do not calculate new values when evaluating a debug statement. Add a flag to enable/disable immediately improving poor values found during cache propagation. Then disable it when processing debug statements. gcc/ PR tree-optimization/100781 * gimple-range-cache.cc (ranger_cache::ranger_cache): Enable new value calculation by default. (ranger_cache::enable_new_values): New. (ranger_cache::disable_new_values): New. (ranger_cache::push_poor_value): Check if new values are allowed. * gimple-range-cache.h (class ranger_cache): New member/methods. * gimple-range.cc (gimple_ranger::range_of_expr): Check for debug statement, and disable/renable new value calculation. gcc/testsuite/ PR tree-optimization/100781 * gcc.dg/pr100781.c: New.
[Bug tree-optimization/100774] [12 Regression] -fcompare-debug failure (length) with -O2 -fno-tree-forwprop --param=evrp-mode=ranger-trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:1ffbfc2659e7e8fa5c5d633869870af8fca5e8ee commit r12-1134-g1ffbfc2659e7e8fa5c5d633869870af8fca5e8ee Author: Andrew MacLeod Date: Thu May 27 11:19:10 2021 -0400 Range invariant global values are also always current. when a range evolves to the point where it becomes a constant, it is marked as invariant. Rather than marking it as always_current in the timestamp, give it the correct timestamp and just never flag it as stale. This will allow other names which use this value to become stale and be recomputed using the newly invariant value. gcc/ PR tree-optimization/100774 * gimple-range-cache.cc (ranger_cache::get_non_stale_global_range): Constant values are also not stale. (ranger_cache::set_global_range): Range invariant values should also have the correct timestamp. gcc/testsuite PR tree-optimization/100774 * g++.dg/pr100774.C: New.
[Bug c++/53598] missed diagnostics / equality comparison result unused [-Wunused-comparison]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53598 --- Comment #4 from Jonathan Wakely --- We should warn about an unused result of any (in)equality, relational, or three-way comparison.
[Bug c++/54379] Suggestion for type attribute similar to warn_unused_result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54379 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Yes I think this can be closed. C++ supports this directly now, without needing GCC extensions.
[Bug fortran/70949] Invalid aggregate against pointer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949 --- Comment #5 from Dominique d'Humieres --- > his PR appears to have been fixed between r11-6743 and r11-6879. Confirmed. Could someone be kind enough to add the test to the test suite?
[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Dominique d'Humieres changed: What|Removed |Added Component|libfortran |other --- Comment #12 from Dominique d'Humieres --- No feedback. This is not a libgfortran bug, moving.
[Bug inline-asm/100785] [9/10/11/12 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785
Jakub Jelinek changed:
What|Removed |Added
Priority|P4 |P2
--- Comment #5 from Jakub Jelinek ---
With:
--- gcc/cfgexpand.c.jj 2021-05-20 09:03:54.147700369 +0200
+++ gcc/cfgexpand.c 2021-05-31 20:48:28.078548261 +0200
@@ -3082,6 +3082,7 @@ expand_asm_stmt (gasm *stmt)
unsigned ninputs = gimple_asm_ninputs (stmt);
unsigned nlabels = gimple_asm_nlabels (stmt);
unsigned i;
+ bool error_seen = false;
/* ??? Diagnose during gimplification? */
if (ninputs + noutputs + nlabels > MAX_RECOG_OPERANDS)
@@ -3140,6 +3141,7 @@ expand_asm_stmt (gasm *stmt)
{
/* ??? Diagnose during gimplification? */
error ("unknown register name %qs in %", regname);
+ error_seen = true;
}
else if (j == -4)
{
@@ -3202,7 +3204,10 @@ expand_asm_stmt (gasm *stmt)
&& REG_P (DECL_RTL (output_tvec[j]))
&& HARD_REGISTER_P (DECL_RTL (output_tvec[j]))
&& output_hregno == REGNO (DECL_RTL (output_tvec[j])))
- error ("invalid hard register usage between output operands");
+ {
+ error ("invalid hard register usage between output operands");
+ error_seen = true;
+ }
/* Verify matching constraint operands use the same hard register
and that the non-matching constraint operands do not use the same
@@ -3225,13 +3230,19 @@ expand_asm_stmt (gasm *stmt)
}
if (i == match
&& output_hregno != input_hregno)
- error ("invalid hard register usage between output operand "
-"and matching constraint operand");
+ {
+ error ("invalid hard register usage between output "
+ "operand and matching constraint operand");
+ error_seen = true;
+ }
else if (early_clobber_p
&& i != match
&& output_hregno == input_hregno)
- error ("invalid hard register usage between earlyclobber "
-"operand and input operand");
+ {
+ error ("invalid hard register usage between "
+ "earlyclobber operand and input operand");
+ error_seen = true;
+ }
}
}
@@ -3307,7 +3318,10 @@ expand_asm_stmt (gasm *stmt)
op = validize_mem (op);
if (! allows_reg && !MEM_P (op))
- error ("output number %d not directly addressable", i);
+ {
+ error ("output number %d not directly addressable", i);
+ error_seen = true;
+ }
if ((! allows_mem && MEM_P (op) && GET_MODE (op) != BLKmode)
|| GET_CODE (op) == CONCAT)
{
@@ -3347,6 +3361,19 @@ expand_asm_stmt (gasm *stmt)
inout_opnum.safe_push (i);
}
+ const char *str = gimple_asm_string (stmt);
+ if (error_seen)
+{
+ ninputs = 0;
+ noutputs = 0;
+ inout_opnum.truncate (0);
+ output_rvec.truncate (0);
+ clobber_rvec.truncate (0);
+ constraints.truncate (0);
+ CLEAR_HARD_REG_SET (clobbered_regs);
+ str = "";
+}
+
auto_vec input_rvec;
auto_vec input_mode;
@@ -3405,7 +3432,7 @@ expand_asm_stmt (gasm *stmt)
}
/* For in-out operands, copy output rtx to input rtx. */
- unsigned ninout = inout_opnum.length();
+ unsigned ninout = inout_opnum.length ();
for (i = 0; i < ninout; i++)
{
int j = inout_opnum[i];
@@ -3459,7 +3486,7 @@ expand_asm_stmt (gasm *stmt)
rtx body = gen_rtx_ASM_OPERANDS ((noutputs == 0 ? VOIDmode
: GET_MODE (output_rvec[0])),
- ggc_strdup (gimple_asm_string (stmt)),
+ ggc_strdup (str),
"", 0, argvec, constraintvec,
labelvec, locus);
MEM_VOLATILE_P (body) = gimple_asm_volatile_p (stmt);
ICEs on:
/* PR inline-asm/100785 */
struct S { int a : 1; };
void
foo (struct S *x)
{
__asm__ ("" : "+m" (x->a)); /* { dg-error "not directly addressable" } */
}
void
bar (struct S *x)
{
__asm__ ("" : "=m" (x->a)); /* { dg-error "not directly addressable" } */
}
void
baz (struct S *x)
{
__asm__ ("" : : "m" (x->a)); /* { dg-error "not directly addressable" } */
}
in foo and bar are fixed, but baz is actually not diagnosed at all and just
ICEs.
So bumping priority to P2, as this isn't error-recovery in the baz case
anymore.
[Bug fortran/88356] [9/10/11/12 Regression] ICE with -Werror in reduce_binary_ac, at fortran/arith.c:1318 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88356 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #9 from Dominique d'Humieres --- > Has this been "accidentally" solved? Apparently yes, closing.
[Bug target/94324] [10/11/12 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324 Dominique d'Humieres changed: What|Removed |Added Component|fortran |target --- Comment #8 from Dominique d'Humieres --- > Shouldn't the component moved to target? No feedback for almost a year, doing so.
[Bug fortran/60576] [9/10/11/12 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #34 from Dominique d'Humieres --- I still get ==33027==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffee0fa7e08 at pc 0x00010ef9b521 bp 0x7ffee0fa7a40 sp 0x7ffee0fa71f0 ... with GCC12 and gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/assumed_rank_7.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fsanitize=address
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Dominique d'Humieres --- > Anything left to do or can the PR be closed? I think so. Please reopen if I missed something.
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #4 from Dominique d'Humieres --- Sorry I didn't use the right compiler. If I do so, I get * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000101443613 f951`splay_tree_min(sp=0x00010001) at splay-tree.c:501:11 498if (!n) 499 return NULL; 500 -> 501while (n->left) 502 n = n->left; 503 504return n; Target 0: (f951) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x000101443613 f951`splay_tree_min(sp=0x00010001) at splay-tree.c:501:11 frame #1: 0x00010002048e f951`gfc_constructor_first(base=) at constructor.c:234:45 frame #2: 0x000164d3 f951`::expand_constructor(base=) at array.c:1790:34 frame #3: 0x00018176 f951`gfc_expand_constructor(gfc_expr*, bool) at array.c:1852:27 frame #4: 0x000180f5 f951`gfc_expand_constructor(e=0x000144505af0, fatal=) at array.c:1875 frame #5: 0x0001000c339f f951`gfc_resolve_expr(gfc_expr*) (.part.0) at resolve.c:7144:29 frame #6: 0x0001000435ea f951`::find_inquiry_ref(p=, newp=0x7ffeefbfe268) at expr.c:1778:20 frame #7: 0x000100047056 f951`::simplify_ref_chain(ref=0x000144505ea0, type=0, p=0x7ffeefbfe2a8) at expr.c:2029:26 frame #8: 0x0001000464be f951`gfc_simplify_expr(gfc_expr*, int) at expr.c:2268:31 frame #9: 0x000100046e2d f951`::simplify_parameter_variable(p=0x0001445049b0, type=0) at expr.c:2112:25 frame #10: 0x000100046bd1 f951`gfc_simplify_expr(gfc_expr*, int) at expr.c:2055:3 frame #11: 0x0001000b4c74 f951`gfc_match_varspec(gfc_expr*, int, bool, bool) at primary.c:2421:22 frame #12: 0x0001000b6bf7 f951`gfc_match_rvalue(result=0x7ffeefbfe598) at primary.c:3590:29 frame #13: 0x000100080218 f951`::match_mult_operand(gfc_expr **) at matchexp.c:157:24 frame #14: 0x000100080200 f951`::match_mult_operand(gfc_expr **) at matchexp.c:211 frame #15: 0x000100080200 f951`::match_mult_operand(result=0x7ffeefbfe660) at matchexp.c:267 frame #16: 0x00010008055d f951`::match_add_operand(result=0x7ffeefbfe6c8) at matchexp.c:356:26 frame #17: 0x00010008083e f951`::match_level_2(result=0x7ffeefbfe740) at matchexp.c:480:27 frame #18: 0x000100080a1d f951`::match_level_3(result=0x7ffeefbfe7c0) at matchexp.c:551:21 frame #19: 0x000100080b66 f951`::match_and_operand(gfc_expr **) at matchexp.c:599:21 frame #20: 0x000100080b5c > This test compiles under lldb. f951`::match_and_operand(result=0x7ffeefbfe840) at matchexp.c:693 frame #21: 0x000100080d9d f951`::match_or_operand(result=0x7ffeefbfe8c0) at matchexp.c:722:25 frame #22: 0x000100080ebd f951`::match_equiv_operand(result=0x7ffeefbfe940) at matchexp.c:765:24 frame #23: 0x000100080fdd f951`::match_level_5(result=0x7ffeefbfe990) at matchexp.c:811:27 frame #24: 0x000100080047 f951`gfc_match_expr(result=0x7ffeefbfea28) at matchexp.c:870:21 frame #25: 0x000100049368 f951`gfc_match_init_expr(result=0x7ffeefbfeaa0) at expr.c:3130:22 frame #26: 0x00010003259b f951`gfc_match_data_decl() at decl.c:2884:28 frame #27: 0x0001000a3d12 f951`::decode_statement() at parse.c:65:15 frame #28: 0x0001000a3d0d f951`::decode_statement() at parse.c:376 frame #29: 0x0001000a9195 f951`next_statement() at parse.c:1321:27 frame #30: 0x0001000ab91c f951`parse_spec(gfc_statement) at parse.c:3981:27 frame #31: 0x0001000aeaf4 f951`::parse_progunit(st=ST_NONE) at parse.c:5918:19 frame #32: 0x0001000b06de f951`gfc_parse_file() at parse.c:6459:22 frame #33: 0x0001001052ac f951`gfc_be_parse_file() at f95-lang.c:212:18 frame #34: 0x000100ec4df4 f951`::compile_file() at toplev.c:457:25 frame #35: 0x00010168c17f f951`toplev::main(int, char**) at toplev.c:2203:24 frame #36: 0x00010168e411 f951`main(argc=2, argv=0x7ffeefbff0c8) at main.c:39:23
[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98712 Patrick Palka changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #3 from Patrick Palka --- *** Bug 100835 has been marked as a duplicate of this bug. ***
[Bug c++/100835] defaulted equality gives wrong answer, if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100835 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Dup *** This bug has been marked as a duplicate of bug 98712 ***
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 --- Comment #3 from CVS Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:a87efd32384ee78ee33d20703deaa65fba81cb2d commit r12-1132-ga87efd32384ee78ee33d20703deaa65fba81cb2d Author: Indu Bhagat Date: Mon May 31 09:19:38 2021 -0700 PR testsuite/100749 - gcc.dg/pch/valid-1.c fails after r12-949 Fix failing pch testcases. Use xstrdup to retain a reliable copy of the debug format str containing the names (df_set_names is a static string var). 2021-05-31 Indu Bhagat gcc/c-family/ PR testsuite/100749 * c-pch.c (c_common_valid_pch): Use xstrdup for debug format set names.
[Bug c/42579] [PATCH] support for obtaining file basename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579 --- Comment #12 from R. Diez --- *** Bug 77488 has been marked as a duplicate of this bug. ***
[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488 R. Diez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #10 from R. Diez --- This issue has been fixed in 42579. *** This bug has been marked as a duplicate of bug 42579 ***
[Bug c/42579] [PATCH] support for obtaining file basename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579 R. Diez changed: What|Removed |Added CC||rdiezmail-gcc at yahoo dot de --- Comment #11 from R. Diez --- What is the target GCC version for __FILE_NAME__? GCC 12.1?
[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #17 from Dominique d'Humieres --- Target issue?
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #3 from Dominique d'Humieres --- Using an instrumented compiler I get % gfcg pr87993.f90 ../../work/libiberty/splay-tree.c:496:19: runtime error: member access within misaligned address 0x00010001 for type 'struct splay_tree_s', which requires 8 byte alignment 0x00010001: note: pointer points here ../../work/libiberty/splay-tree.c:501:11: runtime error: member access within misaligned address 0x30107feedfa for type 'struct splay_tree_node_s', which requires 8 byte alignment 0x30107feedfa: note: pointer points here f951: internal compiler error: Segmentation fault: 11
[Bug other/43979] MPFR can no longer be compiled together with GCC: missing target @MAINTAINER_MODE_TRUE@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43979 --- Comment #2 from Hendrik de Wilde-Geisler --- (In reply to Andrew Pinski from comment #1) > This has been working for me and others. I suspect you are building where > srcdir == objdir which is not really supported. Thanks. I'm quite sure I did not build in srcdir, but I no longer build GCC so resolved is OK.
[Bug preprocessor/77488] Proposal for __FILENAME_ONLY__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #9 from Christophe Lyon --- FWIW, I've recently fixed PR 42579.
[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #13 from Christophe Lyon --- FWIW, I've recently fixed PR 42579.
[Bug c++/100666] [9/10 Regression] warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; ...]', declared with attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666 Jakub Jelinek changed: What|Removed |Added Known to work||11.1.1, 12.0 Summary|[9/10/11/12 Regression] |[9/10 Regression] warning: |warning: ignoring return|ignoring return value of |value of 'constexpr _Tp&& |'constexpr _Tp&& |std::forward(typename |std::forward(typename |std::remove_reference<_Tp>: |std::remove_reference<_Tp>: |:type&) [with _Tp = |:type&) [with _Tp = |std::nullptr_t; ...]', |std::nullptr_t; ...]', |declared with attribute |declared with attribute |'nodiscard' |'nodiscard' |[-Wunused-result] |[-Wunused-result] Known to fail|12.0| --- Comment #5 from Jakub Jelinek --- Fixed on the trunk and for 11.2 so far.
[Bug c++/100646] [11 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 11.2.
[Bug middle-end/100576] [11 Regression] ICE at -O1 and above: in decompose, at wide-int.h:984 since r11-2928-gd14c547abd484d35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/100590] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2) since r11-5002-ge3b3b59683c1e7d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100590 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug c++/100580] [10 Regression] ICE with -fdump-passes since r10-6837-g2473c81cb2d4627f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] ICE with |[10 Regression] ICE with |-fdump-passes since |-fdump-passes since |r10-6837-g2473c81cb2d4627f |r10-6837-g2473c81cb2d4627f --- Comment #6 from Jakub Jelinek --- Fixed also for GCC 11.2.
[Bug rtl-optimization/100342] [10 Regression] wrong code with -O2 -fno-dse -fno-forward-propagate -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] wrong|[10 Regression] wrong code |code with -O2 -fno-dse |with -O2 -fno-dse |-fno-forward-propagate |-fno-forward-propagate |-mno-sse2 |-mno-sse2 --- Comment #16 from Jakub Jelinek --- Fixed also for GCC 11.2.
[Bug c++/100838] [11/12 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/100666] [9/10/11/12 Regression] warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; ...]', declared with at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:718a78fcfb03ca3c552800b510ef3eb085bcbb76 commit r11-8492-g718a78fcfb03ca3c552800b510ef3eb085bcbb76 Author: Jakub Jelinek Date: Tue May 25 17:24:38 2021 +0200 c++: Avoid -Wunused-value false positives on nullptr passed to ellipsis [PR100666] When passing expressions with decltype(nullptr) type with side-effects to ellipsis, we pass (void *)0 instead, but for the side-effects evaluate them on the lhs of a COMPOUND_EXPR. Unfortunately that means we warn about it if the expression is a call to nodiscard marked function, even when the result is really used, just needs to be transformed. Fixed by adding a warning_sentinel. 2021-05-25 Jakub Jelinek PR c++/100666 * call.c (convert_arg_to_ellipsis): For expressions with NULLPTR_TYPE and side-effects, temporarily disable -Wunused-result warning when building COMPOUND_EXPR. * g++.dg/cpp1z/nodiscard8.C: New test. * g++.dg/cpp1z/nodiscard9.C: New test. (cherry picked from commit ad52d89808a947264397e920d7483090d4108f7b)
[Bug c++/100731] [11/12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:742b4b7a644dbb4dd4a5f26c91380db826a6de07 commit r11-8491-g742b4b7a644dbb4dd4a5f26c91380db826a6de07 Author: Jakub Jelinek Date: Tue May 25 16:44:35 2021 +0200 c++tools: Include for exit [PR100731] This TU uses exit, but doesn't include or and relies on some other header to include it indirectly, which apparently doesn't happen on reporter's host. The other headers aren't guarded either and we rely on a compiler capable of C++11, so maybe we can rely on being around unconditionally. 2021-05-25 Jakub Jelinek PR bootstrap/100731 * server.cc: Include . (cherry picked from commit 7a5e9a58fbe27d8b8f04cd18bc6e1dd736e3cd12)
[Bug c++/100646] [11 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3a2fa2e819d4714cecf5048eda2b7e52ba9e3cdd commit r11-8490-g3a2fa2e819d4714cecf5048eda2b7e52ba9e3cdd Author: Jakub Jelinek Date: Thu May 20 09:09:07 2021 +0200 libcpp: Fix up -fdirectives-only handling of // comments on last line not terminated with newline [PR100646] As can be seen on the testcases, before the -fdirectives-only preprocessing rewrite the preprocessor would assume // comments are terminated by the end of file even when newline wasn't there, but now we error out. The following patch restores the previous behavior. 2021-05-20 Jakub Jelinek PR preprocessor/100646 * lex.c (cpp_directive_only_process): Treat end of file as termination for !is_block comments. * gcc.dg/cpp/pr100646-1.c: New test. * gcc.dg/cpp/pr100646-2.c: New test. (cherry picked from commit d15a2d261b24adcbfe5e663b15dde3df5d2b3486)
[Bug middle-end/100576] [11 Regression] ICE at -O1 and above: in decompose, at wide-int.h:984 since r11-2928-gd14c547abd484d35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f4d6ea0c64e45add18294bfbd2ceb6512bbd commit r11-8489-gf4d6ea0c64e45add18294bfbd2ceb6512bbd Author: Jakub Jelinek Date: Wed May 19 12:05:30 2021 +0200 builtins: Fix ICE with unprototyped builtin call [PR100576] For unprototyped builtins the checking we perform is only about whether the used argument is integral, pointer etc., not the exact precision. We emit a warning about the problem though: pr100576.c: In function âfooâ: pr100576.c:9:11: warning: implicit declaration of function âmemcmpâ [-Wimplicit-function-declaration] 9 | int n = memcmp (p, v, b); | ^~ pr100576.c:1:1: note: include ââ or provide a declaration of âmemcmpâ +++ |+#include 1 | /* PR middle-end/100576 */ pr100576.c:9:25: warning: âmemcmpâ argument 3 type is âintâ where âlong unsigned intâ is expected in a call to built-in function declared without prototype +[-Wbuiltin-declaration-mismatch] 9 | int n = memcmp (p, v, b); | ^ It means in the testcase below where the user incorrectly called memcmp with last argument int rather then size_t, the warning stuff in builtins.c ICEs because it compares a wide_int from such a bound with another wide_int which has precision of size_t/sizetype and wide_int asserts the compared wide_ints are compatible. Fixed by forcing the bound to have the right type. 2021-05-19 Jakub Jelinek PR middle-end/100576 * builtins.c (check_read_access): Convert bound to size_type_node if non-NULL. * gcc.c-torture/compile/pr100576.c: New test. (cherry picked from commit e6683450f4a26dae7774be735a3429f48aee9565)
[Bug rtl-optimization/100590] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2) since r11-5002-ge3b3b59683c1e7d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100590 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:490ffb47ad10df1793c4894c7c888d7a10576f1a commit r11-8488-g490ffb47ad10df1793c4894c7c888d7a10576f1a Author: Jakub Jelinek Date: Tue May 18 10:26:45 2021 +0200 regcprop: Avoid DCE of asm goto [PR100590] The following testcase ICEs, because copyprop_hardreg_forward_1 decides to DCE asm goto with REG_UNUSED notes (because the output is unused and asm isn't volatile). But that DCE just removes the asm goto, leaving a bb with two successors and no insn at the end that would allow that. The following patch makes sure we drop that way only INSNs and not JUMP_INSNs or CALL_INSNs. 2021-05-18 Jakub Jelinek PR rtl-optimization/100590 * regcprop.c (copyprop_hardreg_forward_1): Only DCE dead sets if they are NONJUMP_INSN_P. * gcc.dg/pr100590.c: New test. (cherry picked from commit c81704b359283bb54696755ead881ab04136da94)
[Bug c++/100580] [10/11 Regression] ICE with -fdump-passes since r10-6837-g2473c81cb2d4627f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c4d64d136e4e35fb2ee90771848944bb2ffeaf85 commit r11-8487-gc4d64d136e4e35fb2ee90771848944bb2ffeaf85 Author: Jakub Jelinek Date: Tue May 18 10:10:17 2021 +0200 function: Set dummy DECL_ASSEMBLER_NAME in push_dummy_function [PR100580] Last year I've added cgraph_node::get_create calls for the dummy functions used for -fdump-passes, so that it interacts well with pass disabling/enabling which is cgraph uid based. Unfortunately, as the following testcase shows, when assembler hash is present, that wants to compute DECL_ASSEMBLER_NAME and the C++ FE is unprepared to handle it on the dummy functions which don't have DECL_NAME etc. The following patch fixes it by setting up a dummy DECL_ASSEMBLER_NAME on these, so that the FEs don't need to compute it. 2021-05-18 Jakub Jelinek PR c++/100580 * function.c (push_dummy_function): Set DECL_ARTIFICIAL and DECL_ASSEMBLER_NAME on the fn_decl. * g++.dg/other/pr100580.C: New test. (cherry picked from commit 978b62e554ffb4b34844c72d259ce71fcbd87591)
[Bug rtl-optimization/100342] [10/11 Regression] wrong code with -O2 -fno-dse -fno-forward-propagate -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:81c2cd08fafcdc0ff48f6cf440bef86f98822a23 commit r11-8486-g81c2cd08fafcdc0ff48f6cf440bef86f98822a23 Author: Jakub Jelinek Date: Sat May 15 10:12:11 2021 +0200 regcprop: Fix another cprop_hardreg bug [PR100342] On Tue, Jan 19, 2021 at 04:10:33PM +, Richard Sandiford via Gcc-patches wrote: > Ah, ok, thanks for the extra context. > > So AIUI the problem when recording xmm2<-di isn't just: > > [A] partial_subreg_p (vd->e[sr].mode, GET_MODE (src)) > > but also that: > > [B] partial_subreg_p (vd->e[sr].mode, vd->e[vd->e[sr].oldest_regno].mode) > > For example, all registers in this sequence can be part of the same chain: > > (set (reg:HI R1) (reg:HI R0)) > (set (reg:SI R2) (reg:SI R1)) // [A] > (set (reg:DI R3) (reg:DI R2)) // [A] > (set (reg:SI R4) (reg:SI R[0-3])) > (set (reg:HI R5) (reg:HI R[0-4])) > > But: > > (set (reg:SI R1) (reg:SI R0)) > (set (reg:HI R2) (reg:HI R1)) > (set (reg:SI R3) (reg:SI R2)) // [A] && [B] > > is problematic because it dips below the precision of the oldest regno > and then increases again. > > When this happens, I guess we have two choices: > > (1) what the patch does: treat R3 as the start of a new chain. > (2) pretend that the copy occured in vd->e[sr].mode instead > (i.e. copy vd->e[sr].mode to vd->e[dr].mode) > > I guess (2) would need to be subject to REG_CAN_CHANGE_MODE_P. > Maybe the optimisation provided by (2) compared to (1) isn't common > enough to be worth the complication. > > I think we should test [B] as well as [A] though. The pass is set > up to do some quite elaborate mode changes and I think rejecting > [A] on its own would make some of the other code redundant. > It also feels like it should be a seperate âifâ or âelse ifâ, > with its own comment. Unfortunately, we now have a testcase that shows that testing also [B] is a problem (unfortunately now latent on the trunk, only reproduces on 10 and 11 branches). The comment in the patch tries to list just the interesting instructions, we have a 64-bit value, copy low 8 bit of those to another register, copy full 64 bits to another register and then clobber the original register. Before that (set (reg:DI r14) (const_int ...)) we have a chain DI r14, QI si, DI bp , that instruction drops the DI r14 from that chain, so we have QI si, DI bp , si being the oldest_regno. Next DI si is copied into DI dx. Only the low 8 bits of that are defined, the rest is unspecified, but we would add DI dx into that same chain at the end, so QI si, DI bp, DI dx [*]. Next si is overwritten, so the chain is DI bp, DI dx. And then we see (set (reg:DI dx) (reg:DI bp)) and remove it as redundant, because we think bp and dx are already equivalent, when in reality that is true only for the lowpart 8 bits. I believe the [*] marked step above is where the bug is. The committed regcprop.c (copy_value) change (but only committed to trunk/11, not to 10) added else if (partial_subreg_p (vd->e[sr].mode, GET_MODE (src)) && partial_subreg_p (vd->e[sr].mode, vd->e[vd->e[sr].oldest_regno].mode)) return; and while the first partial_subreg_p call returns true, the second one doesn't; before the (set (reg:DI r14) (const_int ...)) insn it would be true and we'd return, but as that reg got clobbered, si became the oldest regno in the chain and so vd->e[vd->e[sr].oldest_regno].mode is QImode and vd->e[sr].mode is QImode too, so the second partial_subreg_p is false. But as the testcase shows, what is the oldest_regno in the chain is something that changes over time, so relying on it for anything is problematic, something could have a different oldest_regno and later on get a different oldest_regno (perhaps with different mode) because the oldest_regno got overwritten and it can change both ways. The following patch effectively implements your (2) above. 2021-05-15 Jakub Jelinek PR rtl-optimization/100342 * regcprop.c (copy_value): When copying a source reg in a wider mode than it has recorded for the value, adjust recorded destination mode too or punt if !REG_CAN_CHANGE_MODE_P. * gcc.target/i386/pr100342.c: New test. (cherry picked from commit 425ad87dcfacbb326d8f448a0f2b4d6b53dcd98f)
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 Anon changed: What|Removed |Added CC||zcsfjvvwjsgomjypri at twzhhq dot c ||om --- Comment #7 from Anon --- Was bitten by this bug today and came to report it, seems like it has already been reported for some time. Please fix sirs.
[Bug c/100842] New: Invalid -Wstringop-truncation with strncat and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100842
Bug ID: 100842
Summary: Invalid -Wstringop-truncation with strncat and -O2
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cerrigno at gmail dot com
Target Milestone: ---
Created attachment 50899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50899=edit
Test source code
I have the following code
#include
char last_str[4];
void copy_strncat(const char *str) {
last_str[0] = '\0';
strncat(last_str, str, sizeof(last_str) - 1);
}
void copy_strncpy(const char *str) {
strncpy(last_str, str, sizeof(last_str));
last_str[sizeof(last_str) - 1] = '\0';
}
void test() {
char str[] = "test";
copy_strncat(str);
copy_strncpy(str);
}
If compiled with "-O2 -Wall" on GCC 11 (tested since GCC 8.1) I get an invalid
warning only in the strncat version the copy function, even if both are safe
and perform (almost) the same thing:
warning: 'strncat' output truncated copying 3 bytes from a string of length 4
[-Wstringop-truncation]
strncat(last_str, str, sizeof(last_str) - 1);
^~~~
In the strncpy version, the -Wstringop-truncation warning is disarmed by the
null terminator assignment after strncpy. I would expect the same from the
assignment made before strncat.
Here you may find my test in godbolt: https://godbolt.org/z/zEaczYzja
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 Martin Liška changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #12 from Martin Liška --- I'll take a look at it.
[Bug c++/100754] Order of multiple inheritance can lead to illegal code jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100754 --- Comment #4 from Martin --- Some additional reading hinted me how the intermediate representation can be help or is enough in itself to reproduce the bug. I have attached the intermediate representation for the Derived object file, by adding -save-temps to the g++ compile line.
[Bug c++/100754] Order of multiple inheritance can lead to illegal code jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100754 --- Comment #3 from Martin --- Created attachment 50898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50898=edit Intermediate representation of "Derived" class. Achieved by adding -save-temps to the g++ compile line.
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 xaizek changed: What|Removed |Added CC||xaizek at posteo dot net --- Comment #11 from xaizek --- > Closing this as fixed. This isn't fixed. I don't think the problem was actually understood. Say you have: * src/myclass.o * tests/myclass.o If you run `gcov -p -x --json-format src/myclass.o` you get myclass.gcov.json.gz for that file, running `gcov -p -x --json-format tests/myclass.o` gives you myclass.gcov.json.gz for the test. Running `gcov -p -x --json-format src/myclass.o tests/myclass.o` gives myclass.gcov.json.gz *FOR THE TEST ONLY*, because gcov created output for src/myclass.o and then replaced it. >From reading your comment I thought that maybe gcov combines information from two files before writing the result to address this issue, but it doesn't. Results you get depends on the order in which files are specified. Either -p and -x need to be obeyed or reports need to be merged. If combining is implemented, might as well combine all reports and write a single file specified on command line (--json-format=myfile.gz or --json-format=- (no compression needed)).
[Bug target/100840] ICE with -O1: in replace_reg, at reg-stack.c:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100840 --- Comment #4 from Chengnian Sun --- Hi Andrew, GCC does not crash on the test program in PR69899. For the program in this PR, GCC does not crash at -O0, but from -O1.
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 --- Comment #2 from vopl at bk dot ru --- https://bugs.llvm.org/show_bug.cgi?id=50540
[Bug fortran/100813] Function of array of pointers to abstract class returning an array since r6-202-gf3b0bb7a560be0f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100813 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-31 Status|UNCONFIRMED |NEW
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-31 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056053.html The patch fixes this PR, however I see an ICE on the original test for pr87993: % gfc pr87993.f90 f951: internal compiler error: Segmentation fault: 11 This test compiles under lldb. Note that the test in the test suite compiles.
[Bug c++/100161] [10 Regression] Impossible to suppress Wtype-limits warning involving template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100161 Martin Liška changed: What|Removed |Added CC||pdimov at gmail dot com --- Comment #6 from Martin Liška --- *** Bug 100827 has been marked as a duplicate of this bug. ***
[Bug c++/100827] [10/11/12 Regression] Compiler crash with Boost.Bimap and Boost.Xpressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100827 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Martin Liška --- Dup. It's fixed on 11 branch and the current master. *** This bug has been marked as a duplicate of bug 100161 ***
[Bug tree-optimization/100817] ICE with -O2: in compute_antic, at tree-ssa-pre.c:2513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100817 --- Comment #4 from Richard Biener --- Created attachment 50897 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50897=edit patch (In reply to Richard Biener from comment #3) > The number of iterations grows linear with loop depth, starting with 6 for > > for (; a;) > for (; a >= 0;) > for (; a;) >for (; a; a += 2) > ; > > adding 2 for every > > for (; a;) > for (; a >= 0;) > > added. The issue is that the postorder on the inverted graph chosen for > iteration is "worst" in how it iterates over the loop nest. Adding an > exit to the innermost loop makes antic iteration iterate two times > independent > on loop depth. For anti iteration it's important to minimize the number of > blocks that are visited before all sucessors are visited, but here the whole > loop nest is only backwards reachable via backedges but there walking the > nest outer-to-inner producing N such blocks. > > Now, doing reverse program order iteration after the initial postorder > traversal would fix this, so I'm going to explore this idea. It's measurably worse for regular CFGs (gcc/*.c), just as example: attribs.c.334t.statistics:146 pre "compute_antic iterations == 2" 39 -attribs.c.334t.statistics:146 pre "compute_antic iterations == 3" 27 +attribs.c.334t.statistics:146 pre "compute_antic iterations == 3" 17 +attribs.c.334t.statistics:146 pre "compute_antic iterations == 4" 9 +attribs.c.334t.statistics:146 pre "compute_antic iterations == 5" 1 still only the very first "iteration" technically requires the postorder on the inverted graph iteration order. I've attached the patch I've used for the measurement. The immediate "fix" would be to remove the assert replacing it with a comment refering to this PR. But not sure if action is really required.
[Bug inline-asm/100785] [9/10/11/12 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
In particular it is the
+ * c-typeck.c (build_unary_op) : Remove left-overs. Issue
+ errors on bit-fields and reverse SSO here and not...
+ (c_mark_addressable): ...here.
change here, when handling inline asm constraints that don't allow registers
the FEs call *mark_addressable:
9265 /* If the operand is going to end up in memory,
9266 mark it addressable. */
9267 if (!allows_reg && !c_mark_addressable (output))
9268output = error_mark_node;
and previously that would diagnose the bitfields but now it doesn't.
So, one way to fix this is restore the error also in c_mark_addressable (and
guess C++ FE too), or at the spots where for inline asm c_mark_addressable is
called also check for bit-fields and diagnose there, or fix the ICE during
expansion where it is diagnosed right now.
E.g. instantiate_virtual_regs_in_insn when seeing errors in inline asm will do:
/* For asm goto, instead of fixing up all the edges
just clear the template and clear input and output operands
and strip away clobbers. */
if (JUMP_P (insn))
{
rtx asm_op = extract_asm_operands (PATTERN (insn));
PATTERN (insn) = asm_op;
PUT_MODE (asm_op, VOIDmode);
ASM_OPERANDS_TEMPLATE (asm_op) = ggc_strdup ("");
ASM_OPERANDS_OUTPUT_CONSTRAINT (asm_op) = "";
ASM_OPERANDS_OUTPUT_IDX (asm_op) = 0;
ASM_OPERANDS_INPUT_VEC (asm_op) = rtvec_alloc (0);
ASM_OPERANDS_INPUT_CONSTRAINT_VEC (asm_op) = rtvec_alloc (0);
}
else
delete_insn (insn);
so perhaps expansion when it detects errors should treat it similarly,
don't emit anything unless it is asm goto and trivialize asm goto.
Note, the cfgexpand.c and FE fixes can be done both.
[Bug bootstrap/100832] s390x-linux-gnu: wrong number of alternatives in the output template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100832 Martin Liška changed: What|Removed |Added CC||joern.rennecke at embecosm dot com ||, marxin at gcc dot gnu.org Priority|P3 |P1 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-31 --- Comment #1 from Martin Liška --- Confirmed, started with r12-1104-gdd1ef00c45ba99ea10082f913c20319b1951defe.
[Bug c++/100838] [11/12 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|-fno-elide-constructors for |[11/12 Regression] |C++14 missing required |-fno-elide-constructors for |destructor call |C++14 missing required ||destructor call since ||r11-5872-g4eb28483004f8291 Ever confirmed|0 |1 Last reconfirmed||2021-05-31 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Started with r11-5872-g4eb28483004f8291.
[Bug c++/100829] [9/10/11/12 Regression] ICE with type that can't be determined since r8-6321-gd78201d30c7c5a8f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100829 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-31 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE with type that can't be |[9/10/11/12 Regression] ICE |determined |with type that can't be ||determined since ||r8-6321-gd78201d30c7c5a8f --- Comment #1 from Martin Liška --- Started with r8-6321-gd78201d30c7c5a8f.
[Bug inline-asm/100785] [9/10/11/12 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785
--- Comment #3 from Jakub Jelinek ---
That revision changed already the original dump:
- __asm__("":"+m" <<< error >>>:);
+ __asm__("":"+m" x->a:);
and during gimplification the asm stmt used to be removed instead of being
kept.
[Bug tree-optimization/98845] [9/10/11 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 23 which are marked as MUST COALESCE.) since r6-528-g465770e43996a132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845 --- Comment #8 from rguenther at suse dot de --- On Mon, 31 May 2021, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845 > > --- Comment #7 from Martin Liška --- > Fixed on master with r12-248-gb58dc0b803057c0e. Yeah, not "fixed" but worked around.
[Bug inline-asm/100785] [9/10/11/12 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r6-4623-gee45a32dae253f7daa966573eb8cb64b2cf7bf52
[Bug c++/100827] [10/11/12 Regression] Compiler crash with Boost.Bimap and Boost.Xpressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100827 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- I can reproduce it, reducing now..
[Bug other/100826] Add that "-fgcse-after-reload" is enabled at "-O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100826 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-05-31 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- I'll take a look. Thanks for the report.
[Bug fortran/100815] [10/11/12 Regression] Segfault assigning to scalar allocatable polymorphic LHS since r11-6253-gce8dcc9105cbd404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[10/11/12 Regression] |[10/11/12 Regression] |Segfault assigning to |Segfault assigning to |scalar allocatable |scalar allocatable |polymorphic LHS |polymorphic LHS since ||r11-6253-gce8dcc9105cbd404 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-31 --- Comment #2 from Martin Liška --- Started with r11-6253-gce8dcc9105cbd404.
[Bug fortran/100814] Fortran memory error on assignment from polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100814 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-05-31 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r11-6253-gce8dcc9105cbd404.
[Bug fortran/100813] Function of array of pointers to abstract class returning an array since r6-202-gf3b0bb7a560be0f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100813 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||vehre at gcc dot gnu.org Summary|Function of array of|Function of array of |pointers to abstract class |pointers to abstract class |returning an array |returning an array since ||r6-202-gf3b0bb7a560be0f0 --- Comment #1 from Martin Liška --- Started with r6-202-gf3b0bb7a560be0f0.
[Bug tree-optimization/100817] ICE with -O2: in compute_antic, at tree-ssa-pre.c:2513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100817 --- Comment #3 from Richard Biener --- The number of iterations grows linear with loop depth, starting with 6 for for (; a;) for (; a >= 0;) for (; a;) for (; a; a += 2) ; adding 2 for every for (; a;) for (; a >= 0;) added. The issue is that the postorder on the inverted graph chosen for iteration is "worst" in how it iterates over the loop nest. Adding an exit to the innermost loop makes antic iteration iterate two times independent on loop depth. For anti iteration it's important to minimize the number of blocks that are visited before all sucessors are visited, but here the whole loop nest is only backwards reachable via backedges but there walking the nest outer-to-inner producing N such blocks. Now, doing reverse program order iteration after the initial postorder traversal would fix this, so I'm going to explore this idea.
[Bug tree-optimization/98845] [9/10/11/12 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 23 which are marked as MUST COALESCE.) since r6-528-g465770e43996a132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845 --- Comment #7 from Martin Liška --- Fixed on master with r12-248-gb58dc0b803057c0e.
[Bug ipa/100812] [10 Regression] lto1-wpa memory hog building openjdk trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100812
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed||2021-05-31
--- Comment #4 from Martin Liška ---
I recommend doing --save-temps --verbose and then running WPA without -quiet
flag. You'll see something like:
$ /home/marxin/bin/gcc/lib/gcc/x86_64-pc-linux-gnu/12.0.0/lto1 -dumpbase
./postgres.wpa -mtune=generic -march=x86-64 -O2 -O2 -O2 -Werror=vla
-Wimplicit-fallthrough=3 -Wformat-truncation=0 -Wno-stringop-truncation
-version -fno-openmp -fno-openacc -fno-pie -fcf-protection=none
-fno-strict-aliasing -fwrapv -fexcess-precision=standard
-fltrans-output-list=./postgres.ltrans.out -fwpa=16 -fresolution=postgres.res
-flinker-output=exec @./postgres.wpa.args.0
...
{heap 66M} {heap 66M} {heap 66M} {heap 66M}
{heap 66M} {GC released 3444k madv_dontneed 72k} {GC 143M
-> 128M} {heap 74M} {heap 74M} {heap 74M}
{GC released 1024k madv_dontneed 14M} {GC trimmed to 123M,
139M mapped} {heap 74M} {heap 74M} {heap 74M}
{heap 74M}
...
so one can identify the memory peak.
[Bug target/100841] New: xtensa-linux: dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100841 Bug ID: 100841 Summary: xtensa-linux: dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int' Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jbg...@lug-owl.de Target Milestone: --- Hi! After having started automated testing again, I noticed this as of ef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3, building with a quite recent GCC: $ ../gcc/configure --target=xtensa-linux --enable-werror-always --enable-languages=all --disable-gcov --disable-shared --disable-threads --without-headers --prefix=/var/lib/laminar/run/gcc-xtensa-linux/2/toolchain-install $ make all-gcc [...] /usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o dwarf2cfi.o -MT dwarf2cfi.o -MMD -MP -MF ./.deps/dwarf2cfi.TPo ../../gcc/gcc/dwarf2cfi.c ../../gcc/gcc/dwarf2cfi.c: In function 'void init_one_dwarf_reg_size(int, machine_mode, rtx, machine_mode, init_one_dwarf_reg_state*)': ../../gcc/gcc/dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int' [-Werror=sign-compare] 291 | if (rnum >= DWARF_FRAME_REGISTERS) cc1plus: all warnings being treated as errors make[1]: *** [Makefile:1141: dwarf2cfi.o] Error 1 make[1]: Leaving directory '/var/lib/laminar/run/gcc-xtensa-linux/2/toolchain-build/gcc' make: *** [Makefile:4414: all-gcc] Error 2 Should be simple to fix I guess. Thanks, Jan-Benedict
[Bug middle-end/88670] [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug 88670 depends on bug 88601, which changed state. Bug 88601 Summary: We may consider adding __builtin_convertvector and __builtin_shufflevector for better compatibility with Clang https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/88601] We may consider adding __builtin_convertvector and __builtin_shufflevector for better compatibility with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 Richard Biener changed: What|Removed |Added Known to work||12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- Fixed for GCC 12.
[Bug c++/88601] We may consider adding __builtin_convertvector and __builtin_shufflevector for better compatibility with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88601 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3 commit r12-1128-gef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3 Author: Richard Biener Date: Fri May 21 11:33:30 2021 +0200 c++/88601 - [C/C++] __builtin_shufflevector support This adds support for the clang __builtin_shufflevector extension to the C and C++ frontends. The builtin is lowered to VEC_PERM_EXPR. Because VEC_PERM_EXPR does not support different sized vector inputs or result or the special permute index of -1 (don't-care) c_build_shufflevector applies lowering by widening inputs and output to the widest vector, replacing -1 by a defined index and subsetting the final vector if we produced a wider result than desired. Code generation thus can be sub-optimal, followup patches will aim to fix that by recovering from part of the missing features during RTL expansion and by relaxing the constraints of the GIMPLE IL with regard to VEC_PERM_EXPR. 2021-05-21 Richard Biener PR c++/88601 gcc/c-family/ * c-common.c: Include tree-vector-builder.h and vec-perm-indices.h. (c_common_reswords): Add __builtin_shufflevector. (c_build_shufflevector): New funtion. * c-common.h (enum rid): Add RID_BUILTIN_SHUFFLEVECTOR. (c_build_shufflevector): Declare. gcc/c/ * c-decl.c (names_builtin_p): Handle RID_BUILTIN_SHUFFLEVECTOR. * c-parser.c (c_parser_postfix_expression): Likewise. gcc/cp/ * cp-objcp-common.c (names_builtin_p): Handle RID_BUILTIN_SHUFFLEVECTOR. * cp-tree.h (build_x_shufflevector): Declare. * parser.c (cp_parser_postfix_expression): Handle RID_BUILTIN_SHUFFLEVECTOR. * pt.c (tsubst_copy_and_build): Handle IFN_SHUFFLEVECTOR. * typeck.c (build_x_shufflevector): Build either a lowered VEC_PERM_EXPR or an unlowered shufflevector via a temporary internal function IFN_SHUFFLEVECTOR. gcc/ * internal-fn.c (expand_SHUFFLEVECTOR): Define. * internal-fn.def (SHUFFLEVECTOR): New. * internal-fn.h (expand_SHUFFLEVECTOR): Declare. * doc/extend.texi: Document __builtin_shufflevector. gcc/testsuite/ * c-c++-common/builtin-shufflevector-2.c: New testcase. * c-c++-common/torture/builtin-shufflevector-1.c: Likewise. * g++.dg/ext/builtin-shufflevector-1.C: Likewise. * g++.dg/ext/builtin-shufflevector-2.C: Likewise.
[Bug c++/100835] defaulted equality gives wrong answer, if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100835 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-05-31 Status|UNCONFIRMED |NEW Known to fail||11.1.0 Ever confirmed|0 |1 Keywords||wrong-code --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/100827] [10/11/12 Regression] Compiler crash with Boost.Bimap and Boost.Xpressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100827 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |WAITING Summary|Compiler crash with |[10/11/12 Regression] |Boost.Bimap and |Compiler crash with |Boost.Xpressive |Boost.Bimap and ||Boost.Xpressive Known to fail||10.1.0, 10.3.0 Known to work||10.2.0 Ever confirmed|0 |1 Target Milestone|--- |10.4 Last reconfirmed||2021-05-31 --- Comment #2 from Richard Biener --- Can you please attach preprocessed source?
[Bug tree-optimization/100817] ICE with -O2: in compute_antic, at tree-ssa-pre.c:2513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100817 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2021-05-31 --- Comment #2 from Richard Biener --- Eh, interesting you managed to construct that worst-case CFG - I'm interested.
[Bug fortran/100815] [10/11/12 Regression] Segfault assigning to scalar allocatable polymorphic LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 Richard Biener changed: What|Removed |Added Keywords||wrong-code Summary|[10.3, 11 regression] |[10/11/12 Regression] |Segfault assigning to |Segfault assigning to |scalar allocatable |scalar allocatable |polymorphic LHS |polymorphic LHS Target Milestone|--- |10.4 Known to fail||10.3.0 Known to work||10.2.0
[Bug tree-optimization/95481] Failure to optimize infinite recursion for empty struct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95481 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-May/571 ||490.html --- Comment #3 from Andrew Pinski --- Patch submitted https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571490.html
[Bug c++/100797] [10/11/12 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 --- Comment #6 from Stephan Bergmann --- (In reply to Jason Merrill from comment #5) > Stephan, can you verify that this fixes the LibreOffice issue? Yes, thanks, tested the master branch fix and it fixes the LibreOffice issue for me.
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-31
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
--- Comment #9 from Kewen Lin ---
(In reply to rguent...@suse.de from comment #5)
> On Fri, 28 May 2021, linkw at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
> >
> > --- Comment #4 from Kewen Lin ---
> > (In reply to rguent...@suse.de from comment #3)
> > > On Fri, 28 May 2021, linkw at gcc dot gnu.org wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
> > > >
> > > > --- Comment #2 from Kewen Lin ---
> > > > (In reply to Richard Biener from comment #1)
> > > >
> > > > Thanks for the comments!
> > > >
> > > > > There's predictive commoning which can do similar transforms and runs
> > > > > after
> > > > > vectorization. It might be it doesn't handle these "simple" cases or
> > > > > that
> > > > > loop dependence info is not up to the task there.
> > > > >
> > > >
> > > > pcom does fix this problem, but it's enabled by default at -O3. Could
> > > > it be
> > > > considered to be run at O2? Or enabled at O2 at some conditions such
> > > > as: only
> > > > for one loop which skips loop carried optimization and isn't vectorized
> > > > further?
> > >
> > > I think pcom should be enabled when vectorization is due to the
> > > interaction with PRE. It could be tamed down (it can do
> > > peeling/unrolling
> > > which is why it is -O3) based on the vectorizer cost model active
> > > if only implicitely enabled ... Things will get a bit messy I guess.
> > >
> >
> > Good point! I prefer this idea to the one guarding cost model in sccvn
> > code.
> >
> > > > > Another option is to avoid the PRE guard with the (very) cheap cost
> > > > > model
> > > > > at the expense of not vectorizing affected loops.
> > > > >
> > > >
> > > > OK, I will benchmark this to see its impact. For the particular loops in
> > > > 554.roms_r, they can be vectorized at cheap cost model, this bmk got
> > > > improved
> > > > at cheap cost model on both Power8 and Power9 (a bit though). So I will
> > > > just
> > > > test the impact on very cheap cost model.
> > >
> > > So another thing to benchmark would be to enable pcom but make sure
> > >
> > > /* Determine the unroll factor, and if the loop should be unrolled,
> > > ensure
> > > that its number of iterations is divisible by the factor. */
> > > unroll_factor = determine_unroll_factor (chains);
> > > scev_reset ();
> > > unroll = (unroll_factor > 1
> > > && can_unroll_loop_p (loop, unroll_factor, ));
> > >
> > > is false for the cheap and very-cheap cost models unless
> > > flag_predictive_commoning is active.
> > >
> >
> > Thanks for the hints! One question: could we just enable non-unroll
> > version of pcom if it's enabled by flag_tree_loop_vectorize implicitly
> > without considering vect cost model? Although the very-cheap and cheap
> > cost model are very likely associated to O2, users still can try dynamic
> > or unlimited cost model at O2, or very-cheap/cheap cost model at O3, it
> > seems not good to map cost model onto unroll decision here directly. Or
> > maybe we check the optimization level? such as:
> >
> > virtual bool
> > gate (function *)
> > {
> > if (flag_predictive_commoning != 0)
> > return true;
> > if (flag_tree_loop_vectorize)
> > {
> > allow_unroll_p = optimize > 2;
>
> But what about -O2 -ftree-vectorize -fno-predictive-commoning? IMHO
> we want to check global_options_set and for "implicit" pcom do not
> allow unrolling and for explicitely disabled pcom do not do any
> pcom at all.
>
> Richard.
OK, the M1 patch followed the suggestion here, not allow unrolling if the pcom
is enabled implicitly by loop vect.
As the evaluation result shows, the way with implied pcom (M1) looks better.
For very cheap cost model, it can make wrf a bit better. For cheap cost model,
the loop carried dependence (M2) did affect some bmks (especially wrf -9%). The
build time increment with M1 looks fine too.
Btw, commenting out two places with "update_ssa
(TODO_update_ssa_only_virtuals)", bootstrapped with the default way and
--with-build-config=bootstrap-O3 way. Will check with regression testing and
SPEC2017 build, but I guess it's another independent patch.
[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 Andrew Pinski changed: What|Removed |Added CC||cnsun at uwaterloo dot ca --- Comment #6 from Andrew Pinski --- *** Bug 100840 has been marked as a duplicate of this bug. ***
[Bug target/100840] ICE with -O1: in replace_reg, at reg-stack.c:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100840 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 69899 though. *** This bug has been marked as a duplicate of bug 69899 ***
[Bug target/100840] ICE with -O1: in replace_reg, at reg-stack.c:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100840 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #2 from Andrew Pinski --- Actually wait, it is not exactly the same bug similar.
[Bug target/90777] [10/11/12 Regression] pr84828 testcase ICEs for m32 x86_64,i686-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90777 Andrew Pinski changed: What|Removed |Added CC||cnsun at uwaterloo dot ca --- Comment #5 from Andrew Pinski --- *** Bug 100840 has been marked as a duplicate of this bug. ***
[Bug target/100840] ICE with -O1: in replace_reg, at reg-stack.c:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100840 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 90777. *** This bug has been marked as a duplicate of bug 90777 ***
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 --- Comment #8 from Kewen Lin --- Created attachment 50896 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50896=edit M1 M2 SPEC2017 P9 eval result
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 --- Comment #7 from Kewen Lin --- Created attachment 50895 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50895=edit Method 2, let pre generate loop carried dependence for very cheap and cheap cost model.
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 --- Comment #6 from Kewen Lin --- Created attachment 50894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50894=edit Method 1, implicitly enable pcom without unrolling once loop vectorization is enabled but pcom isn't set explicitly.
[Bug c/100840] New: ICE with -O1: in replace_reg, at reg-stack.c:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100840
Bug ID: 100840
Summary: ICE with -O1: in replace_reg, at reg-stack.c:714
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210531 (experimental) [master revision
:e6428eb51:e21e93407202e62a10c372595076c593c561bb11] (GCC)
$ cat mutant.c
main() {
long double res;
asm("lxr\t%0,%1\n" : "="(res));
assert(res == 42.);
}
$ gcc-trunk -O1 mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | main() {
| ^~~~
mutant.c: In function ‘main’:
mutant.c:4:3: warning: implicit declaration of function ‘assert’
[-Wimplicit-function-declaration]
4 | assert(res == 42.);
| ^~
mutant.c:1:1: note: ‘assert’ is defined in header ‘’; did you forget
to ‘#include ’?
+++ |+#include
1 | main() {
mutant.c:3:3: error: output constraint 0 must specify a single register
3 | asm("lxr\t%0,%1\n" : "="(res));
| ^~~
during RTL pass: stack
mutant.c:5:1: internal compiler error: in replace_reg, at reg-stack.c:714
5 | }
| ^
0x72f5c6 replace_reg
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:714
0x72f5c6 replace_reg
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:712
0xe6b272 compare_for_stack_reg
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:1379
0xe6b272 subst_stack_regs_pat
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:1998
0xe6bb0a subst_stack_regs
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:2441
0xe6c4ec convert_regs_1
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:3077
0xe6c4ec convert_regs_2
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:3211
0xe6d160 convert_regs
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:3246
0xe6d160 reg_to_stack
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:3371
0xe6d160 rest_of_handle_stack_regs
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:3426
0xe6d160 execute
/tmp/tmp.zS0RT0UjCW-gcc-builder/gcc/gcc/reg-stack.c:3458
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
