[Bug c++/98157] [10 Regression] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in add_candidates, at cp/call.c:5803 since r10-6219-g8b91e848130e45b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98157 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Keywords||ice-on-valid-code
[Bug tree-optimization/98155] [11 Regression] ICE during GIMPLE pass: slp, in vect_init_pattern_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98155 --- Comment #5 from Richard Biener --- Isn't this PR95582?
[Bug tree-optimization/98155] [11 Regression] ICE during GIMPLE pass: slp, in vect_init_pattern_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98155 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Target||x86_64-*-* s390x-*-* Keywords||build Component|lto |tree-optimization CC||rguenth at gcc dot gnu.org
[Bug target/98154] avr-size (avr-binutils v2.35) don't' accept --formart=avr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98154 Richard Biener changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- .
[Bug go/98153] [11 Regression] libgo ftbfs on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98153 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/98152] [11 regression] /usr/bin/env: 'python': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98152 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Richard Biener --- btw, if you require python install.texi should list it as prerequesite (on riscv). Note I strongly encourage to replace with sth else.
[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98146 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142 --- Comment #8 from Richard Biener --- IIRC -fstrict-enums just exposes what the C++ language spec already guarantees and we're much more forgiving by default.
[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067 --- Comment #9 from Iain Buclaw --- (In reply to Iain Buclaw from comment #8) > As a last resort I could just not emit D manifest constants as CONST_DECLs. > They are a nice-to-have from the debugger, but functionally equivalent to C > macros. Or would it be better represent D manifest constants as being part of an anonymous enum type internally?
[Bug tree-optimization/98137] Could use SLP to vectorize if split_constant_offset were smarter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98137 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/98137] Could use SLP to vectorize if split_constant_offset were smarter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98137 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7b4ea2827d2003c8ffc76cd478f8974360cbd78f commit r11-5809-g7b4ea2827d2003c8ffc76cd478f8974360cbd78f Author: Richard Biener Date: Fri Dec 4 11:13:48 2020 +0100 tree-optimization/98137 - enhance split_constant_offset range handling split_constant_offset currently gives up looking at ranges when dealing with possibly wrapping operations for looking through conversions when the downstream analysis does not yield a SSA name. That's overly conservative and we have a nice helper that can deal with arbitrary expresssions. Use that. This helps data reference group analysis so the testcase is fully SLP vectorized, making use of the whole-function "BB" vectorization capabilities we now have. 2020-12-04 Richard Biener PR tree-optimization/98137 * tree-data-ref.c (split_constant_offset_1): Use determine_value_range instead of get_range_info to handle arbitrary expressions. * gcc.dg/vect/bb-slp-pr98137.c: New testcase.
[Bug c/98168] Optimization that can lead to security vulnerabilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98168 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- So no. UD means anything can happen.
[Bug c/98168] New: Optimization that can lead to security vulnerabilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98168
Bug ID: 98168
Summary: Optimization that can lead to security vulnerabilities
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jpegqs at gmail dot com
Target Milestone: ---
Created attachment 49692
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49692=edit
bounds.c
I encountered a bug (98159) that you refused to fix because it is "undefined
behavior". But this code proves that this "compiler" behavior can lead to
security vulnerabilities in some software.
Here GCC thinks that if both signed integers are positive, then the sum of
these integers is also positive. And removes the next bounds check for the
negative values (it could be written different, but this is the common way).
int test(int a, int b, int *buf) {
if (a >= 0 && b >= 0) {
a += b;
// let's check that we are not reading outside the buffer
if (a >= 0 && a < 8) return buf[a];
}
return -1;
}
So this code supposed to read the element A+B from a buffer of 8 values. And if
the sum is out of the buffer, then return -1. But when compiling with GCC
-O2/O3 on x86/x86_64 (and possibly others), you can pass A=0x7fff,
B=0x7fff and access buf[-2] (as with any negative value except -1).
Thus, optimizations that falsely assume that the target machine is performing
signed integer saturation when it is not - should be considered dangerous.
In my opinion, UB in C has a different purpose, it exists because C is a
low-level language and in most cases can use a single machine instruction for a
general operation. So for compilers it should be "target machine behavior", not
"we can do anything". And compilers must maintain this behavior while removing
some operations when optimizing the code.
[Bug c++/98163] ICE symtab_node::verify failed, auto& NTTP specialized with same entity but different type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98163 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Probably a dup of bug 91241.
[Bug tree-optimization/98138] BB vect fail to SLP one case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #3 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> So the expected vectorization builds vectors
>
> { tmp[0][0], tmp[1][0], tmp[2][0], tmp[3][0] }
>
> that's not SLP, SLP tries to build the
>
> { tmp[i][0], tmp[i][1], tmp[i][2], tmp[i][3] }
>
> vector and "succeeds" - the SLP tree turns out to be
> highly inefficient though. So for the stores your desire
> is to see an interleaving scheme with VF 4 (the number of
> iterations). But interleaving fails because it would require
> a VF of 16 and there are not enough iteration in the loop.
>
> The classical SLP scheme degenerates (also due to the plus/minus
> mixed ops) to uniform vectors as we venture beyond the a{0,2} {+,-} a{1,3}
> expression.
>
> Starting SLP discovery from the grouped loads would get things going
> up to the above same expression.
>
> So not sure what's the best approach to this case. The testcase
> can be simplified still showing the SLP discovery issue:
>
> extern void test(unsigned int t[4][4]);
>
> void foo(int *p1, int i1, int *p2, int i2)
> {
> unsigned int tmp[4][4];
> unsigned int a0, a1, a2, a3;
>
> for (int i = 0; i < 4; i++, p1 += i1, p2 += i2) {
> a0 = (p1[0] - p2[0]);
> a1 = (p1[1] - p2[1]);
> a2 = (p1[2] - p2[2]);
> a3 = (p1[3] - p2[3]);
>
> int t0 = a0 + a1;
> int t1 = a0 - a1;
> int t2 = a2 + a3;
> int t3 = a2 - a3;
>
> tmp[i][0] = t0 + t2;
> tmp[i][2] = t0 - t2;
> tmp[i][1] = t1 + t3;
> tmp[i][3] = t1 - t3;
> }
> test(tmp);
> }
>
> So it's basically SLP discovery degenerating to an interleaving scheme
> on the load side but not actually "implementing" it.
IIUC, in current implementation, we get four grouped stores:
{ tmp[i][0], tmp[i][1], tmp[i][2], tmp[i][3] } /i=0,1,2,3/ independently
When all these tryings fail, could we do some re-try on the groups
{ tmp[0][i], tmp[1][i], tmp[2][i], tmp[3][i] } /i=0,1,2,3/
with one extra intermediate layer covering those original groups, then start
from these newly adjusted groups? the built operands should isomorphic then.
May be too hackish?
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 Gabriel Ravier changed: What|Removed |Added Summary|[x86] Failure to optimize |[x86] Failure to optimize |operation on indentically |operation on indentically |shuffled operand into a |shuffled operands into a |shuffle of the result of|shuffle of the result of |the operation |the operation --- Comment #1 from Gabriel Ravier --- PS: I would expect it to be possible to expand this to a much more generic set of operations, and maybe shuffle operands, thus the summary.
[Bug target/98167] New: [x86] Failure to optimize operation on indentically shuffled operand into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
Bug ID: 98167
Summary: [x86] Failure to optimize operation on indentically
shuffled operand into a shuffle of the result of the
operation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
__m128 f(__m128 a, __m128 b) {
return _mm_mul_ps(_mm_shuffle_ps(a, a, 0), _mm_shuffle_ps(b, b, 0));
}
This can be optimized to:
__m128 f(__m128 a, __m128 b) {
__m128 tmp = _mm_mul_ss(a, b);
return _mm_shuffle_ps(tmp, tmp, 0);
}
This transformation is done by LLVM, but not by GCC.
[Bug middle-end/98166] bogus -Wmismatched-dealloc on user-defined allocator and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98166 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98160 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.0 Keywords||diagnostic Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Last reconfirmed||2020-12-07
[Bug middle-end/98166] New: bogus -Wmismatched-dealloc on user-defined allocator and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98166
Bug ID: 98166
Summary: bogus -Wmismatched-dealloc on user-defined allocator
and inlining
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Designating using attribute malloc a pair of functions as an allocator and
deallocator and defining one of them inline to call another allocator or
deallocator not associated with the former pair leads to false positive
warnings.
The test case below (inspired by the one in pr98160) shows how this could
happen. The two pairs of allocators are independent with one another
$ cat a.c && gcc -O2 -S -Wall a.c
void dealloc_shrt (short *p) { __builtin_free (p - 1); }
void dealloc_int (int*);
__attribute__ ((malloc (dealloc_shrt)))
short* alloc_shrt (int);
__attribute__ ((malloc (dealloc_int)))
int* alloc_int (int n) { return (int*)__builtin_malloc (n) + 1; }
void f (int n)
{
{
short *p = alloc_shrt (n);
dealloc_shrt (p);
}
{
int *p = alloc_int (n);
dealloc_int (p);
}
}
In function ‘dealloc_shrt’,
inlined from ‘f’ at a.c:14:5:
a.c:1:32: warning: ‘__builtin_free’ called on pointer returned from a
mismatched allocation function [-Wmismatched-dealloc]
1 | void dealloc_shrt (short *p) { __builtin_free (p - 1); }
|^~
a.c: In function ‘f’:
a.c:13:16: note: returned from a call to ‘alloc_shrt’
13 | short *p = alloc_shrt (n);
|^~
a.c:19:5: warning: ‘dealloc_int’ called on pointer returned from a mismatched
allocation function [-Wmismatched-dealloc]
19 | dealloc_int (p);
| ^~~
a.c:8:39: note: returned from a call to ‘__builtin_malloc’
8 | int* alloc_int (int n) { return (int*)__builtin_malloc (n) + 1; }
| ^~~~
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #37 from abebeos at lazaridis dot com --- ?
[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #1 from Martin Sebor ---
The test case actually exposes two bugs: besides the ICE, the more interesting
problem is the false positive. The warning considers pointers with positive
offsets invalid arguments to all deallocation functions. That's fair for
arguments to pairs of calls to allocation and deallocation functions but not
necessarily when just the deallocator is known and not also the allocator the
pointer was obtained from. A simple test case for that, reduced from the two
translation units in comment #0, is below:
$ cat t.C && gcc -O2 -S -Wall t.C
struct MemoryManager { void* allocate (); };
struct XMemory
{
void* operator new (__SIZE_TYPE__, MemoryManager *mgr)
{
void *p = mgr->allocate ();
return (char*)p + sizeof(MemoryManager);
}
void operator delete (void*, MemoryManager*);
};
struct XMLMutex: XMemory {
XMLMutex();
};
void gValidatorMutex (MemoryManager *mgr) { new (mgr) XMLMutex; }
t.C: In function ‘void gValidatorMutex(MemoryManager*)’:
t.C:18:55: warning: ‘static void XMemory::operator delete(void*,
MemoryManager*)’ called on pointer ‘’ with nonzero offset 1
[-Wfree-nonheap-object]
18 | void gValidatorMutex (MemoryManager *mgr) { new (mgr) XMLMutex; }
| ^~~~
t.C:7:29: note: returned from a call to ‘void* MemoryManager::allocate()’
7 | void *p = mgr->allocate ();
| ~~^~
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed|2020-01-29 00:00:00 |2020-12-6 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- Reduced even further. program p print *, +[ real :: +(1) ] print *, +[ real :: +[1] ] end
[Bug tree-optimization/96963] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963 Martin Sebor changed: What|Removed |Added CC||darklythinking at yahoo dot com --- Comment #4 from Martin Sebor --- *** Bug 98158 has been marked as a duplicate of this bug. ***
[Bug c++/98158] [10/11 Regression] Gcc generates warning about its own generated move assignment operator since r10-3657-gdaa94de24b9afdf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98158
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Keywords||diagnostic
Resolution|--- |DUPLICATE
--- Comment #2 from Martin Sebor ---
The warning works as designed. It's based on the GIMPLE below
(-fdump-tree-strlen) where GCC synthesizes a single store to clear the two
consecutive members. There's code in the warning that tries to deal with this
but a better solution would be to emit IL that c orresponds to valid code
instead of IL that's indistinguishable from a buffer overflow. I.e., instead
of writing the 32 bytes into b write them into (char*) + offsetof (test,
b).
pr96963 already tracks the same problem so I'm going to resolve this as its
duplicate.
[local count: 1073741824]:
# prephitmp_60 = PHI <[(struct basic_string
*)].D.24959._M_local_buf(2), pretmp_59(3)>
MEM[(struct basic_string *)]._M_string_length = 0;
MEM[(char_type &)prephitmp_60] = 0;
_37 = _3(D)->b; <<< address of b
vect__39.58_74 = MEM [(char *
{ref-all}) + 32B];
_39 = MEM <__int128 unsigned> [(char * {ref-all}) + 32B];
_46 = _3(D)->c;
_41 = MEM <__int128 unsigned> [(char * {ref-all}) + 48B];
MEM [(char * {ref-all})_37] = vect__39.58_74;
<<< warning: writing 2 __int128's into b with size 16
_13 = MEM[(const struct basic_string *)]._M_dataplus._M_p;
if ([(const struct basic_string *)].D.24959._M_local_buf != _13)
goto ; [53.47%]
else
goto ; [46.53%]
*** This bug has been marked as a duplicate of bug 96963 ***
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:86c580ded1d58c4e06165d38a0f447d587152179 commit r10-9125-g86c580ded1d58c4e06165d38a0f447d587152179 Author: Harald Anlauf Date: Sun Nov 29 23:23:16 2020 +0100 PR fortran/98017 - Suspected regression using PACK When substituting a parameter variable of type character, the character length was reset to 1. Fix this by copying the length. gcc/fortran/ChangeLog: * expr.c (simplify_parameter_variable): Fix up character length after copying an array-valued expression. gcc/testsuite/ChangeLog: * gfortran.dg/pr98017.f90: New test. (cherry picked from commit bb67ad5cff58a707aaae645d4f45a913d8511c86)
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 98162, which changed state. Bug 98162 Summary: Documentation mentions non-existent option -mcet https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/98162] Documentation mentions non-existent option -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|NEW |RESOLVED --- Comment #3 from H.J. Lu --- Fixed for GCC 11.
[Bug target/98162] Documentation mentions non-existent option -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:9da33826bb9b7d76f85057c18a0b65d0e14baa3d commit r11-5807-g9da33826bb9b7d76f85057c18a0b65d0e14baa3d Author: H.J. Lu Date: Sun Dec 6 07:07:26 2020 -0800 doc: Remove -mcet -mcet was removed by commit 231baae28ef7ff784683fa5a80df119da2b9a99b Author: H.J. Lu Date: Tue Apr 24 16:56:04 2018 + x86/CET: Remove the -mcet command-lint option PR target/98162 * doc/extend.texi: Remove -mcet.
[Bug target/98161] [11 Regression] Incorrect stack realignment on __force_align_arg_pointer__ with -msse4 by r11-446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98161 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from H.J. Lu --- Fixed for GCC 11.
[Bug target/98161] [11 Regression] Incorrect stack realignment on __force_align_arg_pointer__ with -msse4 by r11-446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98161
--- Comment #3 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:6643ca0be6f34786b686415e457de96d0d9fbd2d
commit r11-5806-g6643ca0be6f34786b686415e457de96d0d9fbd2d
Author: H.J. Lu
Date: Sun Dec 6 10:43:16 2020 -0800
x86: Check mode of pseudo register push
commit 266f44a91c0c9705d3d18e82d7c5bab32927a18f
Author: H.J. Lu
Date: Sun May 17 10:10:34 2020 -0700
x86: Allow V1TI vector register pushes
Add V1TI vector register push and split it after reload to a sequence
of:
(set (reg:P SP_REG) (plus:P SP_REG) (const_int -8)))
(set (match_dup 0) (match_dup 1))
added a pseudo register push check. But
(insn 13 12 14 3 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A32])
(reg/v:SI 87 [ srclen ])) "x.c":37:16 54 {*pushsi2}
(expr_list:REG_DEAD (reg/v:SI 87 [ srclen ])
(expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil
is not a pseudo register push. In 64-bit mode, mode of pseudo register
push is TImode. In 32-bit mode, it is DImode. Add pseudo register push
mode check to pseudo_reg_set.
gcc/
PR target/98161
* config/i386/i386-features.c (pseudo_reg_set): Check mode of
pseudo register push.
gcc/testsuite/
* gcc.target/i386/pr98161.c: New test.
[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707 Eyal Rozenberg changed: What|Removed |Added CC||eyalroz at technion dot ac.il --- Comment #12 from Eyal Rozenberg --- Rejection valid code, especially valid code which is not contrived and can well occur in people's real-life work, seems like a high-priority bug. The last substantive comment here, other than dupe-marking-related comments two years ago, is comment #8, asking for this to be fixed - four and a half years ago. Jonathan and others - please try to prioritize fixing this, and even if you can't for some reason - at least explain which this can't be fixed promptly. See also: https://stackoverflow.com/q/65138048/1593077
[Bug target/98161] [11 Regression] Incorrect stack realignment on __force_align_arg_pointer__ with -msse4 by r11-446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98161 H.J. Lu changed: What|Removed |Added Keywords||patch Component|c |target URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Decembe ||r/561224.html --- Comment #2 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561224.html
[Bug target/97865] libtool needs to be updated for Darwin20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #29 from Jürgen Reuter --- (In reply to CVS Commits from comment #28) > The master branch has been updated by Iain D Sandoe : > > https://gcc.gnu.org/g:1352bc88a0525743c952197fb2db6e4f8c091cde > > commit r11-5758-g1352bc88a0525743c952197fb2db6e4f8c091cde > Author: Iain Sandoe > Date: Wed Nov 18 10:06:03 2020 + > Thanks for the commit. I can confirm that with these changes (and analogous ones in our libtool/configure setup) our code built upon shared libraries works again.
[Bug c/98161] [11 Regression] Incorrect stack realignment on __force_align_arg_pointer__ with -msse4 by r11-446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98161 H.J. Lu changed: What|Removed |Added Summary|[11 Regression] Incorrect |[11 Regression] Incorrect |stack realignment on|stack realignment on |__force_align_arg_pointer__ |__force_align_arg_pointer__ |+-mavx |with -msse4 by r11-446 Target Milestone|--- |11.0 CC||crazylht at gmail dot com, ||hjl.tools at gmail dot com, ||wwwhhhyyy333 at gmail dot com Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-06 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is triggered by r11-446. -m32 -msse2 -O2 is OK. But -m32 -msse4 -O2 is not. Hongyu, can you take a look?
[Bug sanitizer/98165] Use of the UB sanitizer links the the program with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165 Bruno Haible changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Bruno Haible --- Thank you. The option '-static-libubsan' indeed has the effect I was looking for.
[Bug sanitizer/98165] Use of the UB sanitizer links the the program with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165 --- Comment #2 from Jakub Jelinek --- You can use -static-libubsan option to achieve the same effect as clang does, LLVM doesn't think linking dynamically is a good idea.
[Bug sanitizer/98165] Use of the UB sanitizer links the the program with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165 --- Comment #1 from Bruno Haible --- Created attachment 49691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49691=edit Test case
[Bug sanitizer/98165] New: Use of the UB sanitizer links the the program with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165 Bug ID: 98165 Summary: Use of the UB sanitizer links the the program with libstdc++ Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org 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: --- I would like to use the 'signed-integer-overflow' sanitizer (part of the undefined behaviour sanitizer) for all my C programs, as a security measure. However, doing so with GCC causes a link dependency towards libstdc++: $ gcc -Wall -fsanitize=signed-integer-overflow foo.c $ ldd ./a.out linux-vdso.so.1 (0x7ffc73977000) libubsan.so.1 => /lib/x86_64-linux-gnu/libubsan.so.1 (0x7fbec9aa) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbec98b6000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbec98b) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbec988e000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fbec96ad000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fbec9692000) /lib64/ld-linux-x86-64.so.2 (0x7fbeca42a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbec9541000) I don't want this, because libstdc++ increases the startup time of programs (from ca. 2 ms to ca. 7 ms). This is with gcc 10.2.0. With clang 11.0.0, I don't have this problem: $ clang -fsanitize=signed-integer-overflow foo.c $ ldd ./a.out linux-vdso.so.1 => (0x7fffc25e3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5fc1486000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f5fc127e000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5fc0f75000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5fc0d71000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f5fc0b5b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5fc0791000) /lib64/ld-linux-x86-64.so.2 (0x7f5fc16a3000)
[Bug c++/98164] New: [C++20] The type displayed in compiler output cannot be reused as displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98164
Bug ID: 98164
Summary: [C++20] The type displayed in compiler output cannot
be reused as displayed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
When displaying the type of a class-type-nontype-template-argument (new with
C++20), these are shown either with parentheses '()' or with curly-brackets
'{}'.
Reusing the type as output (copy-pasting it or via automated parsing of
compiler messages), is only possible if curly-brackets '{}' are used, because
compiler considers '()' in templated types as function calls.
It would seem that the '()' and '{}' are used interchangeably, depending on
some circumstances in the source code.
The test (compile as g++ -std=c++20 -Wall):
#include
struct s {};
template struct r {};
#ifdef FIX
constexpr auto P = r {};
#endif
constexpr auto S = s {};
constexpr auto R = r {};
void g () { using t = decltype (R); };
static_assert (std::is_same_v , decltype (R)>);
// static_assert (std::is_same_v , decltype (R)>);
Here:
1. If FIX is not defined, the type of 't' is displayed using '()':
bug-11.cpp: In function ‘void g()’:
bug-11.cpp:12:20: warning: typedef ‘using t = const struct r’ locally
defined but not used [-Wunused-local-typedefs]
^^
||
12 | void g () { using t = decltype (R); };
|^
2. With -DFIX, the type is displayed using '{}' ("struct r")
bug-11.cpp: In function ‘void g()’:
bug-11.cpp:12:20: warning: typedef ‘using t = const struct r’ locally
defined but not used [-Wunused-local-typedefs]
^^
||
12 | void g () { using t = decltype (R); };
3. The last line can be un-commented to see how the compiler rejects 'const
struct r '.
Since this choice between '()' and '{}' seem (arbitrarily?) dependent on some
external factors (which?), would it be possible to make it always use '{}'?
This would simplify creation of parsing scripts and debugging of constexpr-only
code heavily using dependent types.
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- Care to submit this to gcc-patches?
[Bug driver/98162] Documentation mentions non-existent option -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Decembe ||r/561223.html Last reconfirmed||2020-12-06 --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561223.html
[Bug lto/98155] [11 Regression] ICE during GIMPLE pass: slp, in vect_init_pattern_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98155 --- Comment #4 from Martin Liška --- I was unable to reproduce that with g:bd0f0243869b3941a256ca0ea9c8aca141412f7e for PGO lto-lean configuration on multiple platforms.
[Bug c++/98163] New: ICE symtab_node::verify failed, auto& NTTP specialized with same entity but different type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98163
Bug ID: 98163
Summary: ICE symtab_node::verify failed, auto& NTTP specialized
with same entity but different type.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leni536 at gmail dot com
Target Milestone: ---
g++ (Compiler-Explorer-Build) 11.0.0 20201205 (experimental)
command line flags: -std=c++17 -pedantic-errors
```
template
struct S {};
template
void foo(T) {}
extern const int arr[];
// arr is const int[]
void bar(S s) {
foo(s);
}
const int arr[2] = {1,2};
// arr is const int[2]
void baz(S s) {
foo(s);
}
```
source>:19:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
19 | }
| ^
_Z3fooI1SIL_Z3arrEEEvT_/4 (void foo(T) [with T = S]) @0x7f7216d81330
Type: function definition analyzed
Visibility: no_reorder public weak comdat
comdat_group:_Z3fooI1SIL_Z3arrEEEvT_ one_only
previous sharing asm name: 3
References:
Referring:
Function flags: body
Called by: _Z3baz1SIL_Z3arrEE/2
Calls:
_Z3fooI1SIL_Z3arrEEEvT_/3 (void foo(T) [with T = S]) @0x7f7216d81220
Type: function definition analyzed
Visibility: no_reorder public weak comdat
comdat_group:_Z3fooI1SIL_Z3arrEEEvT_ one_only
next sharing asm name: 4
References:
Referring:
Function flags: body
Called by: _Z3bar1SIL_Z3arrEE/0
Calls:
:19:1: internal compiler error: symtab_node::verify failed
0x1c39f09 internal_error(char const*, ...)
???:0
0xacca22 symtab_node::verify_symtab_nodes()
???:0
0xae8def symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug driver/98162] New: Documentation mentions non-existent option -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162 Bug ID: 98162 Summary: Documentation mentions non-existent option -mcet Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- The documentation page https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html mentions "The following built-in functions are available when -mcet or -mshstk option is used." But an option '-mcet' is not documented (see https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html) and not implemented either: $ gcc -S -O2 a.c -mcet -fcf-protection gcc: error: unrecognized command-line option '-mcet'
[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 Maciej W. Rozycki changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Maciej W. Rozycki --- Do actually close the bug as previously intended.
[Bug lto/98155] [11 Regression] ICE during GIMPLE pass: slp, in vect_init_pattern_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98155 --- Comment #3 from Matthias Klose --- ... building with make profiledbootstrap-lean
[Bug c/98161] New: [11 Regression] Incorrect stack realignment on __force_align_arg_pointer__+-mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98161
Bug ID: 98161
Summary: [11 Regression] Incorrect stack realignment on
__force_align_arg_pointer__+-mavx
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
The bug was initially observed as a miscompilation of wine-5.22 built with
gcc-11 -march=sandybridge. gcc-10 seems to generate something that works.
Here is the extracted executable reproducer. It should return 12, but returns
56:
// $ cat bug.c.c
typedef unsigned short u16;
typedef unsigned int u32;
typedef unsigned char u8;
u32
__attribute__((__force_align_arg_pointer__))
unreach(
const u16 * pu16,
u16 *dst, u32 dstlen,
const u8 *src, u32 srclen
)
{
for (u32 i = dstlen; srclen && i; i--, srclen--, src++, dst++)
{
u16 off = pu16[*src];
if (off)
{
src++; srclen--;
*dst = pu16[off + *src];
}
}
return 56;
}
u32
__attribute__((__force_align_arg_pointer__))
__attribute__((noipa))
bug(
const u16 * pu16,
u16 *dst, u32 dstlen,
const u8 *src, u32 srclen
)
{
if (pu16)
/* Branch should not execute, but stack realignment
* reads wrong 'pu16' value from stack. */
return unreach(pu16, dst, dstlen, src, srclen);
return (srclen < dstlen) ? srclen : dstlen;
}
int main() {
/* Should return 12 */
return bug(0, 0, 12, 0, 34);
}
Running the example:
$ x86_64-pc-linux-gnu-gcc -m32 -fno-PIC -fno-builtin -pipe -fcf-protection=none
-fno-stack-protector -fno-omit-frame-pointer -O1 -mavx -o bug bug.c.c; ./bug ;
echo $?
12
$ x86_64-pc-linux-gnu-gcc -m32 -fno-PIC -fno-builtin -pipe -fcf-protection=none
-fno-stack-protector -fno-omit-frame-pointer -O2 -mavx -o bug bug.c.c; ./bug ;
echo $?
56
Looking at generated code %ebp and %ecx are confused as a pointer to arguments
on stack:
bug:
leal4(%esp), %ecx ; argument pointer
andl$-16, %esp; %esp is realigned
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp; %ebp points to realigned location
pushl %ebx
vmovd 16(%ebp), %xmm1 ; arg3(pu16) BUG: arguments are read
; related to %ebp, not %ecx
vmovd 24(%ebp), %xmm2 ; arg5(dstlen)
movl8(%ebp), %edx ; arg1(srclen)
pushl %ecx
vpminud %xmm2, %xmm1, %xmm0
movl12(%ebp), %ecx
movl20(%ebp), %ebx
vmovd %xmm0, %eax
testl %edx, %edx
je .L21
subl$4, %esp
vmovd %xmm2, (%esp)
pushl %ebx
subl$4, %esp
vmovd %xmm1, (%esp)
pushl %ecx
pushl %edx
callunreach
addl$20, %esp
.L21:
leal-8(%ebp), %esp
popl%ecx
popl%ebx
popl%ebp
leal-4(%ecx), %esp
ret
[Bug c++/98157] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in add_candidates, at cp/call.c:5803 since r10-6219-g8b91e848130e45b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98157
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |10.3
Known to fail||10.2.0
Summary|internal compiler error:|ICE: tree check: expected
|Segmentation, gcc 10.2, |tree that contains ‘decl
|-std=gnu++2a|minimal’ structure, have
||‘tree_list’ in
||add_candidates, at
||cp/call.c:5803 since
||r10-6219-g8b91e848130e45b4
Status|UNCONFIRMED |NEW
Known to work||11.0
Ever confirmed|0 |1
CC||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||nathan at gcc dot gnu.org
Last reconfirmed||2020-12-06
--- Comment #1 from Martin Liška ---
Thanks for the report. It was introduced in r10-6219-g8b91e848130e45b4 and got
fixed in r11-2876-g1f53d8f1d3e7519b.
Is it something we want to backport to GCC 10 branch?
Reduced test-case:
$ cat game_test.ii
struct pair {
int second;
};
template
void for_each(_InputIterator, _Function __f) {
_InputIterator __first;
__f(*__first);
}
template struct array { int operator[](long); };
class span {
public:
template
span(array<_Tp, _ArrayExtent>);
};
enum Trans_NS_constants_gb_playerstate_t { ALLIN };
class gamecards {
void operator==(gamecards);
};
template class gamestate {
protected:
array m_playerstate;
void operator==(gamestate);
};
template class game : gamestate, gamecards {
public:
game(span, int);
array payouts() {
pair __trans_tmp_2;
for_each(&__trans_tmp_2,
[&](auto e) { this->m_playerstate[e.second] == ALLIN; });
}
};
void TestBody() { array cards = game<3>(cards, 0).payouts(); }
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96232, which changed state. Bug 96232 Summary: Failure to optimize bool pattern equivalent to minus 1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96232 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96232] Failure to optimize bool pattern equivalent to minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96232 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for GCC 11.
[Bug tree-optimization/96232] Failure to optimize bool pattern equivalent to minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96232 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8c23434fdadcf4caa1f0e966294c5f67ccf4bcf9 commit r11-5805-g8c23434fdadcf4caa1f0e966294c5f67ccf4bcf9 Author: Jakub Jelinek Date: Sun Dec 6 10:58:10 2020 +0100 [PATCH] phiopt: Handle bool in two_value_replacement [PR796232] The following patch improves code generation on the included testcase by enabling two_value_replacement on booleans. It does that only for arg0/arg1 values that conditional_replacement doesn't handle. Additionally it limits two_value_replacement optimization to the late phiopt like conditional_replacement. 2020-12-06 Jakub Jelinek PR tree-optimization/96232 * tree-ssa-phiopt.c (two_value_replacement): Optimize even boolean lhs cases as long as arg0 has wider precision and conditional_replacement doesn't handle that case. (tree_ssa_phiopt_worker): Don't call two_value_replacement during early phiopt. * gcc.dg/tree-ssa/pr96232-2.c: New test. * gcc.dg/tree-ssa/pr88676-2.c: Check phiopt2 dump rather than phiopt1.
[Bug tree-optimization/96232] Failure to optimize bool pattern equivalent to minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96232 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9e12b8b1819342ef7efac58cf7f4ba4294abe551 commit r11-5804-g9e12b8b1819342ef7efac58cf7f4ba4294abe551 Author: Jakub Jelinek Date: Sun Dec 6 10:55:12 2020 +0100 match.pd: Improve conditional_replacement for x ? 0 : -1 [PR796232] As mentioned in the PR, for boolean x we currently optimize in phiopt x ? 0 : -1 into -(int)!x but it can be optimized as (int) x - 1 which is one less operation both in GIMPLE and in x86 assembly. This patch optimizes it in match.pd, by optimizing -(type)!x when x has boolean range into (type)x - 1. 2020-12-06 Jakub Jelinek PR tree-optimization/96232 * match.pd (-(type)!A -> (type)A - 1): New optimization. * gcc.dg/tree-ssa/pr96232-1.c: New test.
[Bug lto/98155] [11 Regression] ICE during GIMPLE pass: slp, in vect_init_pattern_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98155 --- Comment #2 from Matthias Klose --- 3e2ae3ee285a57455d5a23bd352a68c289130186
[Bug lto/98155] [11 Regression] ICE during GIMPLE pass: slp, in vect_init_pattern_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98155 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-12-06 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Which GCC revision are you testing Matthias?
[Bug c++/98158] [10/11 Regression] Gcc generates warning about its own generated move assignment operator since r10-3657-gdaa94de24b9afdf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98158 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-12-06 Known to work||9.3.0 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Summary|Gcc generates warning about |[10/11 Regression] Gcc |its own generated move |generates warning about its |assignment operator |own generated move ||assignment operator since ||r10-3657-gdaa94de24b9afdf2 Status|UNCONFIRMED |NEW Known to fail||10.2.0, 11.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-3657-gdaa94de24b9afdf2.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 98156, which changed state. Bug 98156 Summary: [Coarray] alloc_comp_1.f90 tests for wrong condition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug testsuite/98156] [Coarray] alloc_comp_1.f90 tests for wrong condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Thomas Koenig --- Fixed by https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bd0f0243869b3941a256ca0ea9c8aca141412f7e Closing.
[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160 Martin Liška changed: What|Removed |Added Known to fail||11.0 Blocks||26163 Priority|P3 |P1 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-12-06 Known to work||10.2.0 Target Milestone|--- |11.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/98160] New: [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160
Bug ID: 98160
Summary: [11 Regression] ICE in default_tree_printer at
gcc/tree-diagnostic.c:270 since
r11-5732-gdce6c58db87ebf7f
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Since the revision 523.xalancbmk_r is broken with -O2 -flto.
There's a reduced test-case:
$ cat 1.ii
namespace xercesc_2_7 {
class MemoryManager;
class XMemory {
public:
void *operator new(unsigned long, MemoryManager *);
void operator delete(void *, MemoryManager *);
};
class XMLPlatformUtils {
public:
static MemoryManager *fgMemoryManager;
};
class XMLMutex : public XMemory {
public:
XMLMutex();
};
void gValidatorMutex() { new (XMLPlatformUtils::fgMemoryManager) XMLMutex; }
} // namespace xercesc_2_7
$ cat 2.ii
namespace xercesc_2_7 {
class MemoryManager;
class XMemory {
void *operator new(unsigned long, MemoryManager *);
};
class MemoryManager {
public:
virtual void *allocate();
};
void *XMemory::operator new(unsigned long, MemoryManager *manager) {
long headerSize(sizeof(MemoryManager));
void *block = manager->allocate();
return block + headerSize;
}
} // namespace xercesc_2_7
$ g++ 1.ii 2.ii -flto -O2 -shared
2.ii: In static member function 'static void* xercesc_2_7::XMemory::operator
new(long unsigned int, xercesc_2_7::MemoryManager*)':
2.ii:13:16: warning: pointer of type 'void *' used in arithmetic
[-Wpointer-arith]
13 | return block + headerSize;
| ~~^~~~
1.ii: In function 'gValidatorMutex':
1.ii:16:66: warning: 'operator delete' called on pointer '_12' with nonzero
offset 8 [-Wfree-nonheap-object]
16 | void gValidatorMutex() { new (XMLPlatformUtils::fgMemoryManager)
XMLMutex; }
| ^
'
during RTL pass: expand
Segmentation fault
0xcc206f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0xd1c6dd default_tree_printer(pretty_printer*, text_info*, char const*, int,
bool, bool, bool, bool*, char const**)
/home/marxin/Programming/gcc/gcc/tree-diagnostic.c:270
0xd1c6dd default_tree_printer(pretty_printer*, text_info*, char const*, int,
bool, bool, bool, bool*, char const**)
/home/marxin/Programming/gcc/gcc/tree-diagnostic.c:247
0x180574c pp_format(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1475
0x17e95a6 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1216
0x17ec107 diagnostic_impl
/home/marxin/Programming/gcc/gcc/diagnostic.c:1366
0x17ec107 inform(unsigned int, char const*, ...)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1445
0x811dc3 warn_dealloc_offset
/home/marxin/Programming/gcc/gcc/builtins.c:13206
0x82003d maybe_emit_free_warning(tree_node*)
/home/marxin/Programming/gcc/gcc/builtins.c:13344
0x838ece initialize_argument_information
/home/marxin/Programming/gcc/gcc/calls.c:2629
0x838ece expand_call(tree_node*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/calls.c:4009
0x96bb54 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:11252
0x84cb3d expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:282
0x84cb3d expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2831
0x84cb3d expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3835
0x84cb3d expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3999
0x851ffa expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6043
0x853b66 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6727
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
