[Bug rtl-optimization/99199] [9/10/11/12 Regression] Very large boolean expression leads to quite a few return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 --- Comment #7 from Andrew Pinski --- Also for this testcase seem it should just return true even :).
[Bug rtl-optimization/99199] [9/10/11/12 Regression] Very large boolean expression leads to quite a few return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 --- Comment #6 from Andrew Pinski --- I don't see it on the trunk really; I wonder what changed, I know there has been many jump threading changes and even some phiopt changes which might have changed this for the better. Though I do see "label:ret" at least twice so it is not fully fixed. One thing I did notice is that is LLVM saves a lot of registers: pushrbp pushr15 pushr14 pushr13 pushr12 pushrbx :) Which solves the problem there :).
[Bug d/103728] Allow to run unittests before main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103728 --- Comment #2 from Pierrick Bouvier --- Problem with command line approach is that it implies to patch all our scripts, which is *really* boring. At this point, manually adding rt_options string in all binaries is easier. Alas, there is no environment variable for controlling this. When unittests semantic was changed in dmd, from what I read, dmd maintainers were not open to keep an "old" mode as a compiler option. I understand it's not the role of gdc to control this, but I still think it could be useful to offer a flag (that automatically generates rt_options symbol).
[Bug tree-optimization/85390] [9/10/11/12 Regression] possible missed optimisation / regression from 6.3 with conditional expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85390
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.1.0
Last reconfirmed||2021-12-16
Target Milestone|--- |9.5
Keywords||needs-bisection
Ever confirmed|0 |1
Summary|possible missed |[9/10/11/12 Regression]
|optimisation / regression |possible missed
|from 6.3 with conditional |optimisation / regression
|expression |from 6.3 with conditional
||expression
CC||pinskia at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Component|rtl-optimization|tree-optimization
Known to work||6.4.0
--- Comment #3 from Andrew Pinski ---
Ok, the issue is just dumb luck:
Take:
extern int a, b, c;
int f(int x)
{
__builtin_prefetch((void *) (__SIZE_TYPE__)(x ? a : b));
return c;
}
int f1(int x)
{
int t = x ? a :b;
__builtin_prefetch((void *)(__SIZE_TYPE__)t);
return c;
}
The f1 uses cmov while f does not.
The gimple level difference is there is two cast (one in each branch) for f
while only one cast outside of the PHI node.
But that was that way even in GCC 6.
I wonder what changed in GCC 7 which caused this issue to appear.
[Bug debug/103742] [12 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions --param=early-inlining-insns=82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103742 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||ice-on-valid-code
[Bug tree-optimization/103741] [12 Regression] ICE in prepare_vec_mask, at tree-vect-stmts.c:1808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/103743] New: PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
Bug ID: 103743
Summary: PPC: Inefficient equality compare for large 64-bit
constants having only 16-bit relevant bits in high
part
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
int overflow();
int negOverflow(long long in)
{
if (in == 0x8000LL)
{
return overflow();
}
return 0;
}
Generates:
negOverflow(long long):
.quad .L.negOverflow(long long),.TOC.@tocbase,0
.L.negOverflow(long long):
li 9,-1
rldicr 9,9,0,0
cmpd 0,3,9
beq 0,.L10
li 3,0
blr
.L10:
mflr 0
std 0,16(1)
stdu 1,-112(1)
bl overflow()
nop
addi 1,1,112
ld 0,16(1)
mtlr 0
blr
.long 0
.byte 0,9,0,1,128,0,0,0
Instead of:
li 9,-1
rldicr 9,9,0,0
cmpd 0,3,9
Expected output:
rotldi 3,3,1
cmpdi 0,3,1
This should be only applied if constant fits into 16-bit and if those 16-bit
are in the first 32-bit.
[Bug ipa/103734] IPA-CP opportunity for imagick in SPECCPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734 --- Comment #2 from Hongtao.liu --- (In reply to Tamar Christina from comment #0) > When using --param ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=20 on > imagick the hot functions MorphologyApply and GetVirtualPixelsFromNexus get > replaced by specialized versions that are much smaller and faster. > > Some other benchmarks like leela also get very small uplifts but the imagick > one is worth 14%. Both flags seem to be needed. Observe similar thing on ICX with -param=inline-min-speedup=3
[Bug rtl-optimization/92925] RTL expansion throws away misalignment info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92925
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #7 from Andrew Pinski ---
(insn 16 15 0 (set (mem:TI (plus:DI (reg/f:DI 87)
(const_int 8 [0x8])) [2 bptr_6(D)->aD.1982[i_12]+0 S16 A64])
(const_int 0 [0])) "/app/example.cpp":11:15 -1
(nil))
Note you need to add:
asm("":::"memory");
at the end of the function set; otherwise everything is optimized away :).
[Bug ipa/103734] IPA-CP opportunity for imagick in SPECCPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug debug/103742] New: [12 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions --param=early-inlining-insns=82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103742
Bug ID: 103742
Summary: [12 Regression] '-fcompare-debug' failure (length)
with -O2 -fnon-call-exceptions
--param=early-inlining-insns=82
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Created attachment 52011
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52011=edit
auto-reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fnon-call-exceptions
--param=early-inlining-insns=82 -fcompare-debug testcase.C
x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure
$ diff -u *gkd
--- a-testcase.C.gkd2021-12-16 06:38:14.832032631 +0100
+++ a-testcase.gk.C.gkd 2021-12-16 06:38:14.912032192 +0100
@@ -279,7 +279,7 @@
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0]))
(nil)))
-(code_label # 0 0 4 18 (nil) [1 uses])
+(code_label # 0 0 4 19 (nil) [1 uses])
(note # 0 0 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 4 (set (reg:DI 1 dx [orig:87 _9 ] [87])
(mem:DI (reg/f:DI 0 ax [orig:86 iftmp.4_8 ] [86]) [
*iftmp.4_8.m_value+0 S8 A64])) "testcase.C":5:61# {*movdi_internal}
@@ -340,6 +340,6 @@
(jump_insn # 0 0 5 (set (pc)
(label_ref #))# {jump}
(nil)
- -> 18)
+ -> 19)
(barrier # 0 0)
(note # 0 0 NOTE_INSN_DELETED)
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-6011-20211215204558-gab18659afc0-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-6011-20211215204558-gab18659afc0-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211216 (experimental) (GCC)
[Bug tree-optimization/103741] New: [12 Regression] ICE in prepare_vec_mask, at tree-vect-stmts.c:1808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
Bug ID: 103741
Summary: [12 Regression] ICE in prepare_vec_mask, at
tree-vect-stmts.c:1808
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc 12.0.0 alpha20211212 snapshot (g:0b52083ea2c2dd9897031fdc3802a68fd4aa45ef)
ICEs when compiling the following testcase w/ -march=armv8-a+sve -O1:
long int m, n;
int
qux (int z)
{
return 4 >> z ? z : 0;
}
int
bar (long int y)
{
return y ? 3 : 2;
}
__attribute__ ((simd)) int
foo (int x)
{
long int a = x & m;
int b = bar (x) / n;
return qux (b) == a;
}
% aarch64-linux-gnu-gcc-12.0.0 -march=armv8-a+sve -O1 -c et9fimir.c
during GIMPLE pass: vect
et9fimir.c: In function 'foo.simdclone.0':
et9fimir.c:16:1: internal compiler error: in prepare_vec_mask, at
tree-vect-stmts.c:1808
16 | foo (int x)
| ^~~
0x8b2dd2 prepare_vec_mask
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-stmts.c:1808
0x1c877d0 vectorizable_operation
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-stmts.c:6372
0x1ca0218 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-stmts.c:11193
0x11cab9d vect_transform_loop_stmt
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-loop.c:9302
0x11e93b5 vect_transform_loop(_loop_vec_info*, gimple*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-loop.c:9738
0x121e6c7 vect_transform_loops
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vectorizer.c:1003
0x121e6c7 try_vectorize_loop_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vectorizer.c:1133
0x121e6c7 try_vectorize_loop
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vectorizer.c:1162
0x121ef74 execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vectorizer.c:1278
[Bug tree-optimization/100221] Takes two passes at DSE to remove some dead stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100221 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/100221] Takes two passes at DSE to remove some dead stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100221
Andrew Pinski changed:
What|Removed |Added
Summary|missed optimization for |Takes two passes at DSE to
|dead code elimination at|remove some dead stores
|-O3 (vs. -O1, -Os, -O2) |
--- Comment #3 from Andrew Pinski ---
Reduced testcase even further to show the problem (note -O2 and -O3 both now
don't optimize):
extern void foo(void);
int a, b;
static int c;
int main() {
if (c)
foo ();
int *g =
int **h =
int ***h1 =
if (a)
while (b)
b = 0;
}
[Bug tree-optimization/100221] missed optimization for dead code elimination at -O3 (vs. -O1, -Os, -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100221 --- Comment #2 from Andrew Pinski --- If we force inline f: like: [[gnu::always_inline]] static inline void f() -O2 behavior becomes the same as -O3. -O3: Deleted dead store: # .MEM_7 = VDEF <.MEM_6> hD.2116[0] = -O2: ipa-modref: call stmt f (); ipa-modref: call to void f()/3 does not use ref: h[0] alias sets: 3->3 Deleted dead store: # .MEM_7 = VDEF <.MEM_6> hD.2116[0] = ipa-modref: call stmt f (); ipa-modref: call to void f()/3 does not use ref: g alias sets: 2->2 Deleted dead store: # .MEM_6 = VDEF <.MEM_2> gD.2115 = &_ZL1cD.2103; I don't see why there is a difference between g and h here except g had its address taken before maybe tracking MEM though the loop is what is causing the issue.
[Bug c++/82894] [9/10/11/12 Regression] Inherited member functions do not create ambiguity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82894
--- Comment #2 from Andrew Pinski ---
Even one without templates:
struct S {
char f();
};
struct wrapper : private S {
int f(int = 0);
using S::f;
};
void g(void)
{
wrapper t;
t.f();
}
And yes it was rejected in GCC 6.4.0.
[Bug c++/82894] [9/10/11/12 Regression] Inherited member functions do not create ambiguity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82894
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||7.1.0, 8.1.0
Keywords||needs-bisection
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-12-16
Summary|Inherited member functions |[9/10/11/12 Regression]
|do not create ambiguity |Inherited member functions
||do not create ambiguity
Known to work||5.1.0, 6.1.0, 6.4.0
Target Milestone|--- |9.5
--- Comment #1 from Andrew Pinski ---
Confirmed.
A C++98 testcase:
struct S {
char f();
};
template
struct wrapper : private T {
int f(int = 0);
using T::f;
};
void g(void)
{
wrapper t;
t.f();
}
[Bug c++/69623] Invalid deduction of non-trailing template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623
--- Comment #5 from Andrew Pinski ---
Full testcase where both declarations should be an error:
template void f() { } // error
template void g() { } // error
[Bug c++/69623] Invalid deduction of non-trailing template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623 Andrew Pinski changed: What|Removed |Added CC||xmh970252187 at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 103740 has been marked as a duplicate of this bug. ***
[Bug c++/103740] A function template declaration with a template-parameter in the last that has no default argument or can be deduced shall be ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103740 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 69623. *** This bug has been marked as a duplicate of bug 69623 ***
[Bug c++/102449] template parameter with default argument is used without being verified during explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102449 --- Comment #1 from Andrew Pinski --- I think this is valid code as the compiler can deduce that First is int. All compilers I have tried accept the code.
[Bug c++/103740] New: A function template declaration with a template-parameter in the last that has no default argument or can be deduced shall be ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103740
Bug ID: 103740
Summary: A function template declaration with a
template-parameter in the last that has no default
argument or can be deduced shall be ill-formed
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
template void g() { }
This template declaration should be ill-formed since it violates [temp.param]
p14
A template parameter pack of a function template shall not be followed by
another template parameter unless that template parameter can be deduced from
the parameter-type-list ([dcl.fct]) of the function template or has a default
argument ([temp.deduct]).
Template parameter `U` satisfies none of them, hence the declaration should be
ill-formed. It is also a formal example that the comment says it is an error.
[Bug tree-optimization/91789] Value ranges determined from comparisons not used transitively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789 --- Comment #7 from Andrew Macleod --- hmm. yeah. we have the knowledge... but how to apply it efficiently. === BB 4 Imports: a_3(D) Exports: a_3(D) b_2(D) int VARYING a_3(D) int VARYING Relational : (b_2(D) >= a_3(D)) : if (a_3(D) < 0) goto ; [INV] else goto ; [INV] 4->5 (T) a_3(D) : int [-INF, -1] 4->6 (F) a_3(D) : int [0, +INF] We know the relationship upon entry to BB 4, but with no reference to b_2, there is no reason to update b_2's range. b_2 may never be reference again. === BB 6 Imports: b_2(D) Exports: b_2(D) b_2(D) int VARYING : if (b_2(D) < 0) goto ; [INV] else goto ; [INV] 6->7 (T) b_2(D) : int [-INF, -1] 6->8 (F) b_2(D) : int [0, +INF] And upon entry to BB6, we do know that a_3 is [0, +INF], but with no reference to a_3 in this block, we don't see any reason to look to see if there is a relationship. And with no further references to a_3 in the IL, we wont propagate its value to here either. THe problem is that unless we do an exhaustive search of every possible relation of b_2, there is nothing in the IL at each point to indicate we should look at the other name. Perhaps it isnt as bad as I make it sound. r perhaps I can add relations to the export list for a block and have gori figure it out. IE, in bb4 a_3 is the only export, and we can calculate a range for it. If we note at this point that there is a relation between a_3 and b_2, perhaps I can add b_2 to the export list as well, and the GORI how to process the relation much like it process recalculations. IF we have c_9 = a_3 - 10 somewhere in the program, we note the dependence of c_9 on a_3, and we "recalculate" c_9 as [0,+INF] - 10 == [-10, +INF-10] on that edge. Perhaps I can likewise add relations to this recomputation and flag b_3 as a recomputation.. Since the relation is technically "true", it could be solved for b_2 as [1, 1] = b_2(D) >= [1, +INF] and everything should just work... hmm. I shall give it a go after a bit more thought.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 38541, which changed state. Bug 38541 Summary: function parameter type T(*)[] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38541 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug c++/38541] function parameter type T(*)[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38541 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED Alias||cwg393 Blocks||94404 --- Comment #4 from Andrew Pinski --- [Moved to DR at the November, 2014 meeting.] So closing as invalid. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug c++/38541] function parameter type T(*)[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38541 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #3 from Jiang An --- These cases are made valid by CWG DR393 (https://wg21.link/cwg393).
[Bug target/102069] [12 regression] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069 Jiu Fu Guo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jiu Fu Guo --- Updated the case in the trunk with the requirement of vec_char_add.
[Bug testsuite/102946] [12 Regression] gcc.dg/vect/pr101145_1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946 Jiu Fu Guo changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Jiu Fu Guo --- In trunk cases updated to run on the target which supports the cases (e.g. vec_char_add)
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 Jiu Fu Guo changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #19 from Jiu Fu Guo --- So, mark this as resolved.
[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #23 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #22) > (In reply to Hongtao.liu from comment #15) > > > Is the behavior well defined for n >= 64? I got > > > > > > foo.c:11:19: warning: left shift count >= width of type > > > [-Wshift-count-overflow] > > >11 | long mask = 1ll << 65; > > > | ^~ > > According to C99 > > The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are > > filled with zeros. If E1 has an unsigned type, the value of the result is E1 > > × 2E2, reduced modulo one more than the maximum value representable in the > > result type. If E1 has a signed type and nonnegative value, and E1 × 2E2 is > > representable in the result type, then that is the resulting value; > > otherwise, the behavior is undefined. > > > > So yes, it's well defined, and the result is zero. > > No, that isn't well defined in any C or C++ versions. > E.g. in C++: > https://eel.is/c++draft/expr.shift#1 > The behavior is undefined if the right operand is negative, or greater than > or equal to the width of the promoted left operand. > C99 6.5.7: > If the value of the right operand is negative or is > greater than or equal to the width of the promoted left operand, the > behavior is undefined. > What varies is whether shifting negative values left is well defined or not, > or whether shifting bits into the sign bit of signed type is well defined or > not. thanks for correction， I missed another paragraph。 cut from WG14 The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 × 2 E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 × 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined. end- So, the result is undefined.
[Bug tree-optimization/101754] Missed fold for a/b*b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101754 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/95817] Failure to optimize shift with constant to compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95817
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Severity|normal |enhancement
Last reconfirmed||2021-12-16
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Well canonicalization reasons is still good as we don't optimize:
bool f(int a)
{
return (!(a >> 7)) == !((unsigned)a > 127);
}
To just return 1;
[Bug tree-optimization/97434] Missed dead code optimization from data flow analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97434 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/91789] Value ranges determined from comparisons not used transitively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #6 from Andrew Pinski --- We have in evrp: Registering value_relation (b_2(D) >= a_3(D)) on (2->4) ... Relational : (b_2(D) >= a_3(D)) : if (a_3(D) < 0) goto ; [INV] else goto ; [INV] 4->5 (T) a_3(D) : int [-INF, -1] 4->6 (F) a_3(D) : int [0, +INF] But then we don't update the value relationship for what we had for b_2 for the branch where a_3 >= 0, we should also a range for b_2(D) of [0, +INF] for 4->6.
[Bug libstdc++/102445] [meta-bug] std::regex issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 Bug 102445 depends on bug 84738, which changed state. Bug 84738 Summary: stack-overflow in regex_match https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84738 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 Jonathan Wakely changed: What|Removed |Added CC||semi1 at posteo dot de --- Comment #12 from Jonathan Wakely --- *** Bug 84738 has been marked as a duplicate of this bug. ***
[Bug libstdc++/84738] stack-overflow in regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84738 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- This is another dup of PR 86164, due to the recursive implementation. *** This bug has been marked as a duplicate of bug 86164 ***
[Bug libstdc++/102445] [meta-bug] std::regex issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 Bug 102445 depends on bug 93502, which changed state. Bug 93502 Summary: std::regex_match uses stack space proportional to input string length https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 Jonathan Wakely changed: What|Removed |Added CC||nyh at math dot technion.ac.il --- Comment #11 from Jonathan Wakely --- *** Bug 93502 has been marked as a duplicate of this bug. ***
[Bug libstdc++/93502] std::regex_match uses stack space proportional to input string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #7 from Jonathan Wakely --- Yes, it's definitely due to the recursive implementation. Nothing whatsoever to do with storing data on the stack. *** This bug has been marked as a duplicate of bug 86164 ***
[Bug tree-optimization/95423] Failure to optimize separated multiplications by x and square of x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95423 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/61582] C++11 regex memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 --- Comment #23 from Jonathan Wakely --- (In reply to M Welinder from comment #22) > FWIW, there is an excellent overview of regular expression engine pitfalls > and methods here: > > https://swtch.com/~rsc/regexp/regexp1.html > https://swtch.com/~rsc/regexp/regexp2.html > https://swtch.com/~rsc/regexp/regexp3.html Yes, there have been links to the first one in libstdc++ headers since 2013.
[Bug tree-optimization/94757] GCC does not optimise unsigned multiplication known not to overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94757 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Severity|normal |enhancement See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97997 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed for GCC 11 by r11-5444-ga3ebc13492ff23 (PR 97997), this is almost a dup of bug 97997 but not exactly.
[Bug tree-optimization/97997] Missed optimization: Multiply of extended integer cannot overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97997 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||missed-optimization Severity|normal |enhancement
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 --- Comment #8 from cqwrteur --- (In reply to Jonathan Wakely from comment #7) > Huh, I must have checked in an old draft ... which is odd as I only have one > open on my desktop, and it's the current one. > > Reopening then. And we need an LWG issue for the std::hash problem. WG21 is a joke. Forcing the standard library vendor to provide things like EH and RTTI, but no std::array, std::move, std::addressof. We need P0709 asap.
[Bug c++/70816] bogus error __builtin_strcmp is not a constant expression in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816 --- Comment #4 from Jonathan Wakely --- Our std::char_traits has similar branches for constant evaluation (and the rest of the library does too for memcpy etc.)
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #7 from Jonathan Wakely --- Huh, I must have checked in an old draft ... which is odd as I only have one open on my desktop, and it's the current one. Reopening then. And we need an LWG issue for the std::hash problem.
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #6 from Jiang An --- (In reply to Jonathan Wakely from comment #2) > cppreference is wrong, is not freestanding. https://eel.is/c++draft/tab:headers.cpp.fs is still listed as a freestanding header in the recent working draft. Is there any changed made?
[Bug tree-optimization/98953] Failure to optimize two reads from adjacent addresses into one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98953 --- Comment #5 from Andrew Pinski --- *** Bug 102391 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102391] Failure to optimize adjacent 8-bit loads into a single bigger load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102391 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 98953. *** This bug has been marked as a duplicate of bug 98953 ***
[Bug tree-optimization/102495] optimize some consecutive byte load pattern to word load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102495 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed||2021-12-15 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed, this might be a dup.
[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698
--- Comment #2 from Sergei Trofimovich ---
Aha, sounds good. Let's consider it's an user error to mix -g* options with
`__attribute__((section(".data")))` applied to `.code` objects.
[Bug sanitizer/91707] [10/11/12 Regression] spurious stringop-overflow warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91707
--- Comment #12 from Martin Sebor ---
Here's a slightly simplified test case for GCC 12:
$ cat z.c && gcc -O2 -S -Wall -fsanitize=undefined z.c
extern void f (unsigned n, long[n], const long[n]);
void g (unsigned n, const long a[n])
{
long b[n + 1];
f (n, b + 1, a);
long c[n + 1];
(void)c;
}
z.c: In function ‘g’:
z.c:6:4: warning: ‘f’ accessing 34359738360 bytes in a region of size 0
[-Wstringop-overflow=]
6 |f (n, b + 1, a);
|^~~
z.c:6:4: note: referencing argument 2 of type ‘long int[]’
z.c:6:4: note: referencing argument 3 of type ‘const long int[]’
z.c:1:13: note: in a call to function ‘f’
1 | extern void f (unsigned n, long[n], const long[n]);
| ^
[Bug d/103728] Allow to run unittests before main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103728
--- Comment #1 from Iain Buclaw ---
Not sure if there'd be much help from the compiler on this front, as it's a
runtime library feature that unittests are executed in the first place - the
compiler simply generates functions in the proper place for the library to find
them.
See
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libphobos/libdruntime/rt/dmain2.d;h=b363e3fea4fc55d9f6941030dc808e5129bd38c2;hb=HEAD#l491
The old behaviour was of `runAll()` was:
if (rt_init() && runModuleUnitTests())
tryExec({ result = mainFunc(args); });
> someone suggested to use this:
> version (unittest) extern(C) __gshared string[] rt_options = [ "testmode=run-
> main" ];
> It works well with gdc-12, but it is very cryptic and still hard to add in all
> our binaries (we have dozens).
A second way of doing the would be to run the program with the command-line
option: --DRT-testmode=run-main
The options itself gets filtered from the `string[] args` parameter of D main,
so it won't affect tests where arguments are given to binaries (unless the
--DRT option appears after `--`).
[Bug c++/102229] [11 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 Marek Polacek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] |'decltype(auto)' cannot be |'decltype(auto)' cannot be |cv-qualified|cv-qualified --- Comment #11 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:06d5dcef72542baf49ac245cfde2ad7ecef0916b commit r12-6008-g06d5dcef72542baf49ac245cfde2ad7ecef0916b Author: Marek Polacek Date: Fri Dec 10 15:38:35 2021 -0500 c++: Allow constexpr decltype(auto) [PR102229] My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says "If the placeholder-type-specifier is of the form type-constraint[opt] decltype(auto), T shall be the placeholder alone." But this made us reject 'constexpr decltype(auto)', which, after clarification from CWG, should be valid. [dcl.type.auto.deduct]/4 is supposed to be a syntactic constraint, not semantic, so it's OK that the constexpr marks the object as const. As a consequence, checking TYPE_QUALS in do_auto_deduction is too late, and we have a FIXME there anyway. So in this patch I'm attempting to detect 'const decltype(auto)' earlier. If I'm going to use TYPE_QUALS, it needs to happen before we mark the object as const due to constexpr, that is, before grokdeclarator's /* A `constexpr' specifier used in an object declaration declares the object as `const'. */ if (constexpr_p && innermost_code != cdk_function) ... Constrained decltype(auto) was a little problem, hence the TYPENAME check. But in a typename context you can't use decltype(auto) anyway, I think. PR c++/102229 gcc/cp/ChangeLog: * decl.c (check_decltype_auto): New. (grokdeclarator): Call it. * pt.c (do_auto_deduction): Don't check decltype(auto) here. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/decltype-auto5.C: New test.
[Bug d/103739] Bootstrap broken on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739 --- Comment #2 from Segher Boessenkool --- Hi! I have no idea why not. $ gdc --version gdc (GCC) 9.3.1 20200410 and it says Configured with: /home/segher/src/gcc/configure --prefix=/home/segher/tot --enable-languages=c,c++,fortran,ada,d,objc,obj-c++ --disable-libgomp
[Bug middle-end/54802] Trivial code changes result in different assembly with respect to rotations and bswap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54802 Andrew Pinski changed: What|Removed |Added Known to fail||4.9.4 Ever confirmed|0 |1 Last reconfirmed||2021-12-15 Keywords||needs-bisection Known to work||5.1.0 Status|UNCONFIRMED |NEW
[Bug tree-optimization/92903] Cannot elide byteswap when only needed to compare to multiple constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92903 Andrew Pinski changed: What|Removed |Added Keywords||TREE --- Comment #5 from Andrew Pinski --- So for x86 since GCC 9, we are able to optimize it at the RTL level as combine added 2->2 instruction combining. Still need to be done at the tree level.
[Bug tree-optimization/94071] Missed optimization with endian and alignment independent memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94071 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- Looks like bswap does not handle the case where addr is non-constant even for the pointer case.
[Bug fortran/26766] [F2003] Recursive I/O still (again) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26766 --- Comment #10 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:4a5e71f2348adcc49939804889d9f1a64d97005a commit r12-6006-g4a5e71f2348adcc49939804889d9f1a64d97005a Author: H.J. Lu Date: Sat Nov 13 06:11:41 2021 -0800 Sync with binutils: Support the PGO build for binutils+gdb Sync with binutils for building binutils with LTO: 1dbde357be3 Add missing changes to Makefile.tpl af019bfde9b Support the PGO build for binutils+gdb Add the --enable-pgo-build[=lto] configure option. When binutils+gdb is not built together with GCC, --enable-pgo-build enables the PGO build: 1. First build with -fprofile-generate. 2. Use "make maybe-check-*" to generate profiling data and pass -i to make to ignore errors when generating profiling data. 3. Use "make clean" to remove the previous build. 4. Rebuild with -fprofile-use. With --enable-pgo-build=lto, -flto=jobserver -ffat-lto-objects are used together with -fprofile-generate and -fprofile-use. Add '+' to the command line for recursive make to support -flto=jobserver -ffat-lto-objects. NB: --enable-pgo-build=lto enables the PGO build with LTO while --enable-lto enables LTO support in toolchain. BZ binutils/26766 * Makefile.tpl (BUILD_CFLAGS): New. (CFLAGS): Append $(BUILD_CFLAGS). (CXXFLAGS): Likewise. (PGO_BUILD_GEN_FLAGS_TO_PASS): New. (PGO_BUILD_TRAINING_CFLAGS): Likewise. (PGO_BUILD_TRAINING_CXXFLAGS): Likewise. (PGO_BUILD_TRAINING_FLAGS_TO_PASS): Likewise. (PGO_BUILD_TRAINING_MFLAGS): Likewise. (PGO_BUILD_USE_FLAGS_TO_PASS): Likewise. (PGO-TRAINING-TARGETS): Likewise. (PGO_BUILD_TRAINING): Likewise. (all): Add '+' to the command line for recursive make. Support the PGO build. * configure.ac: Add --enable-pgo-build[=lto]. AC_SUBST PGO_BUILD_GEN_CFLAGS, PGO_BUILD_USE_CFLAGS and PGO_BUILD_LTO_CFLAGS. Enable the PGO build in Makefile. * Makefile.in: Regenerated. * configure: Likewise.
[Bug d/103528] [12 regression] d21 doesn't build on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103528 --- Comment #5 from Iain Buclaw --- (In reply to Rainer Orth from comment #0) > * toplevel configure needs to make certain that the bootstrap gdc can compile > *and link* some trivial D program. Letting the build proceed otherwise > leads > to confusing link errors as seen here. gnat can do away without such a > test > because there are no gnat without libgnat configurations (either you have a > fully working GNAT or you have none), while the gdc without libphobos > situation is quite common in GCC. I'm on the side-line with that observation though, gdc without libphobos has been defaulted in configure.tgt more because I lack the means for testing such a broad amount of targets (such as non-x86 BSDs). When someone does test it (powerpc64le-freebsd) the report I get back is usually that it works fine. Rather gdc without libphobos is more of an exception, because the compiler heavily depends on it existing anyway, with many high-level features lowered into calls of core druntime helper functions. Without a runtime, this severely limits what you can do in the language to a strict subset (that might as well be C). To pick a similar example, is this a bug? Or can it be explained away with documentation? --- checking for long long... yes checking size of long long... configure: error: in `/work/gcc/build/gcc': configure: error: cannot compute sizeof (long long) See `config.log' for more details make[1]: *** [Makefile:4511: configure-gcc] Error 1 make[1]: Leaving directory '/work/gcc/build' make: *** [Makefile:985: all] Error 2 --- (config.log) configure:6450: checking size of long long configure:6455: g++ -o conftest -g conftest.cpp >&5 /usr/bin/ld: cannot find -lstdc++ collect2: error: ld returned 1 exit status configure:6455: $? = 1 configure: program exited with status 1 ---
[Bug c++/70816] bogus error __builtin_strcmp is not a constant expression in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816 Louis Dionne changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment #3 from Louis Dionne --- We are having to add a workaround in libc++ to implement constexpr std::string: https://reviews.llvm.org/D115795 It would be awesome if this could be fixed! (if so, please drop us a line and we'll remove our workaround)
[Bug tree-optimization/67413] Complex NOP expanded to several operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67413 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > It would just work. Except the two casts are not the same in the case of negative as I mentioned in comment #2 :).
[Bug tree-optimization/67413] Complex NOP expanded to several operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67413 --- Comment #4 from Andrew Pinski --- As for the other testcase: y_3 = x_2(D) & -4294967296; z_4 = (intD.9) x_2(D); _1 = (long intD.12) z_4; _5 = _1 | y_3; If we could optimize: z_4 = (intD.9) x_2(D); _1 = (long intD.12) z_4; Into: _1 = x_2(D) & 4294967295; It would just work.
[Bug tree-optimization/67413] Complex NOP expanded to several operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67413 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Blocks||101926 --- Comment #3 from Andrew Pinski --- Maybe for: _1 = REALPART_EXPR ; _2 = (long long unsigned intD.23) _1; _3 = IMAGPART_EXPR ; _4 = (long long unsigned intD.23) _3; _6 = COMPLEX_EXPR <_2, _4>; We should just create a VCE, I don't know if that is a good idea or not, complex int in cases like this are not used that much anyways so Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926 [Bug 101926] [meta-bug] struct/complex argument passing and return should be improved
[Bug tree-optimization/90839] Detect lsb ones counting loop (final value replacement?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90839 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/90967] -Os produces more code than -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90967 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug d/103739] Bootstrap broken on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739 --- Comment #1 from Iain Buclaw --- Why is the library not installed alongside the host compiler though? The D core runtime compiles and works well on powerpc64-linux.
[Bug tree-optimization/83351] Missed optimization in math expression: sin^2(a) + cos^2(a) == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83351 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/67242] Missing optimization with float IV in SCEV-CCP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67242 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/77387] -Wstrict-overflow pessimizes VRP in some cases for ABS_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77387 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||8.1.0 Known to fail||7.5.0 --- Comment #4 from Andrew Pinski --- EVRP in 8+: _1: [0, 127] i_2(D): VARYING x_4: [0, +INF] x_5: [0, 127] EVRP in 7.5.0: _1: VARYING i_2(D): VARYING x_4: [0, +INF(OVF)] x_5: VARYING Looks to be fixed for GCC 8.
[Bug sanitizer/91707] [10/11/12 Regression] spurious stringop-overflow warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91707
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2021-01-21 00:00:00 |2021-12-15
Known to fail|11.0|11.2.0, 12.0
--- Comment #11 from Martin Sebor ---
GCC 11 still issues the same -Wstringop-overflow as GCC 10 plus another one for
the call to md_copy_dims():
In function ‘real_from_complex_dims’,
inlined from ‘md_test’ at pr91707.c:14:4:
pr91707.c:7:13: warning: writing 8 bytes into a region of size 0
[-Wstringop-overflow=]
7 |odims[0] = 2;
|~^~~
pr91707.c: In function ‘md_test’:
pr91707.c:13:9: note: destination object ‘dimsR.8’ of size 0
13 |long dimsR[D + 1];
| ^
In function ‘real_from_complex_dims’,
inlined from ‘md_test’ at pr91707.c:14:4:
pr91707.c:8:4: warning: ‘md_copy_dims’ accessing 34359738360 bytes in a region
of size 0 [-Wstringop-overflow=]
8 |md_copy_dims(D, odims + 1, idims);
|^
pr91707.c: In function ‘md_test’:
pr91707.c:8:4: note: referencing argument 2 of type ‘long int *’
pr91707.c:2:13: note: in a call to function ‘md_copy_dims’
2 | extern void md_copy_dims(unsigned int D, long odims[D], const long
idims[D]);
| ^~~~
The second warning is for the md_copy_dims() call in the following IL:
[count: 0]:
md_copy_dims (4294967295, [(void
*) + 8B], idims_13(D));
__builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data1, 0);
[local count: 1073741824]:
dimsR.8 ={v} {CLOBBER};
return;
The first warning is gone in GCC 12 and only the second one remains. It's
triggered by the same md_copy_dims() call with the first argument in excess of
the size of the arrays passed to the function:
[count: 0]:
_29 = dimsR.1_23 + 8;
md_copy_dims (4294967295, _29, idims_13(D));
__builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data1, 0);
[Bug tree-optimization/64541] FRE pass optimization failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 --- Comment #5 from cqwrteur --- (In reply to Jonathan Wakely from comment #4) > (In reply to Jonathan Wakely from comment #2) > > cppreference is wrong, is not freestanding. > > I've fixed it now. thank you.
[Bug tree-optimization/64319] add alias runtime check to remove load after load redundancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64319 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > cppreference is wrong, is not freestanding. I've fixed it now.
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 --- Comment #3 from cqwrteur --- (In reply to Jonathan Wakely from comment #2) > cppreference is wrong, is not freestanding. okay.
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- cppreference is wrong, is not freestanding.
[Bug libstdc++/54924] Warn for std::string constructor with wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54924 --- Comment #16 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #14) > Created attachment 43350 [details] > Patch to use __builtin_object_size in std::string > > So it isn't lost, here's a prototype I was working on last year (which only > helps if you use -Wsystem-headers). Huh, I forgot about this patch and then reinvented that wheel: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581376.html
[Bug d/103739] New: Bootstrap broken on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739 Bug ID: 103739 Summary: Bootstrap broken on powerpc64-linux Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: segher at gcc dot gnu.org Target Milestone: --- gdc -fno-PIE -c -g -O2 -fversion=IN_GCC -Wall -Wdeprecated -fno-common -o d/access.o -MT d/access.o -MMD -MP -MF d/.deps/access.TPo -I/home/segher/src/gcc/gcc/d -J/home/segher/src/gcc/gcc/d/dmd -J/home/segher/src/gcc/gcc/d/dmd/res /home/segher/src/gcc/gcc/d/dmd/access.d d21: error: cannot find source code for runtime library file 'object.d' d21: note: dmd might not be correctly installed. Run 'dmd -man' for installation instructions. d21: note: config file: not found import path[0] = /home/segher/src/gcc/gcc/d make[3]: *** [d/access.o] Error 1 This is with --enable-languages=all. This should not build D if that cannot work (if that is what the problem is, I have no idea).
[Bug c/103738] No warning when setting deprecated fields using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103738 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-15 Keywords||diagnostic Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug libstdc++/103726] --disable-hosted-libstdcxx (freestanding C++) does not provide as what standard requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103726 --- Comment #1 from cqwrteur --- also here is a weird thing i find. coroutine_handle has a template specification of std::hash, but std::hash is in which is not freestanding. What should standard library do? Should libstdc++ provide it or not?
[Bug c++/103711] Virtual base destroyed twice when an exception is thrown in a derived class' constructor called from a delegated constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > Without the library dependency, and without the defaulted destructor (since ^^^ Oops, ignore that part, I meant to delete it.
[Bug c++/103711] Virtual base destroyed twice when an exception is thrown in a derived class' constructor called from a delegated constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711
--- Comment #4 from Jonathan Wakely ---
Without the library dependency, and without the defaulted destructor (since GCC
int constructions = 0;
int destructions = 0;
struct A
{
A()
{
constructions++;
}
virtual ~A() {
destructions++;
}
};
struct B : public virtual A
{
B(int)
{
};
B() : B(1)
{
throw -1;
}
virtual ~B() = default;
};
struct C : public B
{
};
int main() {
try
{
C c;
}
catch (int)
{
}
if (constructions != destructions)
throw 1;
return 0;
}
[Bug c++/103711] Virtual base destroyed twice when an exception is thrown in a derived class' constructor called from a delegated constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-12-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Usually when a constructor throws you don't call the destructor, because the object hasn't finished being constructed yet. But for a delegating constructor, once the target constructor finishes the object's lifetime has begun, and so the destructor *does* get run. It seems that both B::B() and B::B(int) think they are in-charge of the virtual base and so both run the destructor for it. G++ has had this bug since delegating constructor were first implemented in GCC 4.7.0
[Bug c/103738] No warning when setting deprecated fields using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103738 Niklas Haas changed: What|Removed |Added Attachment #52009|no_warning.c|warning.c filename|| Attachment #52009|No deprecation warning |Deprecation warning description|produced|produced --- Comment #1 from Niklas Haas --- Comment on attachment 52009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52009 Deprecation warning produced Accidentally attached the wrong version of the file, fixing.
[Bug c/103738] New: No warning when setting deprecated fields using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103738 Bug ID: 103738 Summary: No warning when setting deprecated fields using designated initializers Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gcc at haasn dot dev Target Milestone: --- Created attachment 52009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52009=edit No deprecation warning produced Deprecated attributes on struct members are ignored when setting those fields using designated initializers. The attached example should produce a warning, but it does not. Contrast the following alternative code: struct foo foo; foo.bar = 5; This does produce a deprecation warning as expected: no_warning.c: In function ‘main’: no_warning.c:8:5: warning: ‘bar’ is deprecated [-Wdeprecated-declarations] 8 | foo.bar = 5; | ^~~ no_warning.c:2:9: note: declared here 2 | int bar __attribute((deprecated)); | ^~~
[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722
--- Comment #1 from Vladimir Makarov ---
(In reply to Joseph S. Myers from comment #0)
> Created attachment 52003 [details]
> preprocessed source
>
> Build the attached code (from glibc) with -O2 for sh4-linux-gnu. This
> produces an ICE:
>
> malloc-debug.c: In function '__debug_realloc':
> malloc-debug.c:267:1: error: insn does not satisfy its constraints:
> (insn 955 1863 2 2 (set (reg:SI 76 fr12 [314])
> (reg:SI 146 pr)) 189 {movsi_ie}
> (nil))
> during RTL pass: postreload
> malloc-debug.c:267:1: internal compiler error: in extract_constrain_insn, at
> recog.c:2670
> 0x5eec04 _fatal_insn(char const*, rtx_def const*, char const*, int, char
> const*)
> /scratch/jmyers/glibc/many12/src/gcc/gcc/rtl-error.c:108
> 0x5eec2a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> /scratch/jmyers/glibc/many12/src/gcc/gcc/rtl-error.c:119
> 0xcab367 extract_constrain_insn(rtx_insn*)
> /scratch/jmyers/glibc/many12/src/gcc/gcc/recog.c:2670
> 0xc71acd reload_cse_simplify_operands
> /scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:407
> 0xc732bc reload_cse_simplify
> /scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:190
> 0xc732bc reload_cse_regs_1
> /scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:238
> 0xc7584b reload_cse_regs
> /scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:66
> 0xc7584b execute
> /scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:2355
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 Bill Schmidt changed: What|Removed |Added Assignee|wschmidt at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #9 from Bill Schmidt --- After some discussion, Segher will take a run at this one, so unassigning myself.
[Bug testsuite/103737] new test case decltype-bitfield1.C fails in r11-9363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103737 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Done.
[Bug testsuite/78136] gcc.dg/cpp/trad/include.c fails with newer glibc versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78136 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED CC||tnfchris at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #5 from Tamar Christina --- Sorry missed the message, these tests now pass.
[Bug fortran/103694] [12 Regression] ICE in gfc_conv_expr_op, at fortran/trans-expr.c:3882 since r12-3993-gb19bbfb148250536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103694 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Martin Liška from comment #1) > Started with r12-3993-gb19bbfb148250536. Are you sure about that? All releases >= 7 ICE for me.
[Bug tree-optimization/103690] [12 Regression] ICE: in build2, at tree.c:4985 with -g -O2 -fno-tree-dce -fno-tree-dse -fno-tree-fre --param=max-jump-thread-duplication-stmts=94 since r12-2591-g2e96b5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103690
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment #4 from Alex Coplan ---
Here's a slightly cleaned up testcase which fails with the same options FWIW:
typedef int *int_ptr;
struct __normal_iterator {
int *_M_current;
__normal_iterator(const int_ptr &__i) : _M_current(__i) {}
void foo() { __normal_iterator(_M_current - 1); }
};
void deallocate(int *);
struct vector {
int *_M_start;
int *_M_finish;
__normal_iterator end() { return _M_finish; }
int back() {
__normal_iterator t = _M_finish;
t.foo();
}
void foo();
};
int *p1, *p2;
int last, result;
void vector::foo() {
for (int i; i;)
while (i) {
__normal_iterator t1 = end();
int *p3, *__old_start = _M_start, *__new_finish;
long __count = - __old_start;
if (__count > 0)
__builtin_memmove(, __old_start, __count);
p1 = + __count;
p2 = p1 + 1;
__count = _M_finish - t1._M_current;
if (__count)
__builtin_memmove(p2, t1._M_current, __count);
p3 = p2 + __count;
__new_finish = p3;
if (__old_start)
deallocate(__old_start);
_M_finish = __new_finish;
back();
}
}
also confirmed on aarch64-linux-gnu.
[Bug c++/103408] ICE when requires auto(x) in C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103408 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Patrick Palka --- Fixed for GCC 12.
[Bug fortran/103693] [12 Regression] ICE in gfc_array_dimen_size(): Bad EXPR_ARRAY expr since r12-4967-gbcf3728abe848888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103693 --- Comment #2 from anlauf at gcc dot gnu.org --- Gerhard, the issue here is class(*), parameter :: a(1,2) = 2 which we do not yet support, and where there is a duplicate by you already.
[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 11.3/12.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 103198, which changed state. Bug 103198 Summary: ICE for requires requires clause with varadic templates https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103198 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103198] ICE for requires requires clause with varadic templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103198 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed for GCC 11.3/12.
