[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 Iain Sandoe changed: What|Removed |Added Attachment #46110|0 |1 is obsolete|| --- Comment #68 from Iain Sandoe --- Created attachment 46176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46176&action=edit revised fixincludes patch. So I have an answer about the language implications. Any C++ program containing _Atomic is using a reserved identifier, and so is "ill-formed no diagnostic required", per [lex.name]/3 Therefore, it's standards-conforming for a [C++] implementation to make such identifiers keywords (as GCC does for __attribute__, for example) Apparently, this is intentional extension and is only one of a longer list of such keywords that clang++ accepts. Since, according to the discussion above, this is not a bug in the compiler but rather in using a non-portable extension, perhaps we should not expect any change to the headers. The patch attached include the generated files, and I'd be grateful if folks would test it (right now I have limited access to Darwin test boxen, but it seems to DTRT for me) - I will post to @patches, but leave commit until it's confirmed that it's working.
[Bug c/90081] stdint constant macros evaluating to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081 --- Comment #6 from Harald van Dijk --- (In reply to Guy Perfect from comment #5) > (In reply to Harald van Dijk from comment #4) > That was my line of thinking: supplying a cast in the macro. Keep in mind that inside #if expressions, there cannot be and will not be any cast. That's the reason I included the + there. > Even in the > case of negative values being cast to unsigned types, the language spec > provides a rule for that, so the behavior is defined independent of the > implementation: As Andreas Schwab pointed out, the behaviour of UINT8_C in that case is undefined, even if the behaviour of a cast would be defined. It simply does not matter what happens in that case. > I think the ticket was marked "resolved invalid" prematurely, as there's > clearly a meaningful problem and a meaningful solution. I do think it's rightly closed, but for a reason not yet mentioned: these macros are not defined by GCC's . If this required compiler magic to implement, it would be primarily a GCC bug, but the fact that no compiler magic is needed means this is purely a glibc bug, so should be filed there.
[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #3 from Marc Glisse --- (In reply to Frederico Lamberti Pissarra from comment #2) > (In reply to Andrew Pinski from comment #1) > > It is <0 when sqrt is called and it is due setting errno. Not a bug. > > Hu... interesting. But why the inefficient code? What do you mean by inefficient? What would you suggest instead? We generate a fast sqrtss and only in the rare case where there is an error we call the libc sqrt function to let it report errors the way it wants. -fno-math-errno is the way to say we don't care about this kind of error reporting.
[Bug c++/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #5 from Martin Liška ---
(In reply to bin cheng from comment #4)
> In get_scaled_computation_cost_at, we have very big ratio between
> bb_count/loop_count:
>
> (gdb) p data->current_loop->latch->count
> $50 = {static n_bits = 61, static max_count = 2305843009213693950, static
> uninitialized_count = 2305843009213693951, m_val = 158483, m_quality =
> profile_guessed_local}
> (gdb) p gimple_bb(at)->count
> $51 = {static n_bits = 61, static max_count = 2305843009213693950, static
> uninitialized_count = 2305843009213693951, m_val = 1569139790, m_quality =
> profile_guessed_local}
> (gdb) p 1569139790 / 158483
> $52 = 9900
> (gdb) p cost
> $53 = {cost = 20, complexity = 2, scratch = 1}
> (gdb) p 19 * 9900
> $54 = 188100
>
> as a result, sum_cost soon reaches to overflow of infinite_cost. Shall we
> cap the ratio so that it doesn't grow too quick? Of course, some benchmark
> data is needed for this heuristic tuning.
I would implement the capping in comp_cost struct where each individual
operator
can cap to infinite. What do you think Bin?
>
>
> Another problem is the generated binary has segment fault issue even
> compiled O0:
>
> $ ./g++ -O0 pr90078.cc -o a.out -ftemplate-depth=100 -ftime-report -g
> -std=c++14
> $ gdb --args ./a.out
>
> Dump of assembler code for function main():
>0x00400572 <+0>: push %rbp
>0x00400573 <+1>: mov%rsp,%rbp
>0x00400576 <+4>: sub$0x2625a020,%rsp
>0x0040057d <+11>:lea-0x2625a020(%rbp),%rax
>0x00400584 <+18>:mov%rax,%rdi
> => 0x00400587 <+21>:callq 0x4006c0 100, 100>::Tensor4()>
>0x0040058c <+26>:lea-0x4c4b410(%rbp),%rax
>0x00400593 <+33>:lea-0xe4e1c10(%rbp),%rdx
>
> The segment fault happens at the callq instruction.
Yes, same happens also for clang. It's a stack overflow:
$ g++ pr90078.cpp -ftemplate-depth=111 -fsanitize=address && ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==5750==ERROR: AddressSanitizer: stack-overflow on address 0x7fffd9da3af0 (pc
0x004011cb bp 0x7fffdc60 sp 0x7fffd9da3af0 T0)
#0 0x4011ca in main (/home/marxin/Programming/testcases/a.out+0x4011ca)
#1 0x76d32b7a in __libc_start_main ../csu/libc-start.c:308
#2 0x401109 in _start (/home/marxin/Programming/testcases/a.out+0x401109)
SUMMARY: AddressSanitizer: stack-overflow
(/home/marxin/Programming/testcases/a.out+0x4011ca) in main
==5750==ABORTING
[Bug rtl-optimization/87703] UBSAN: poly-int.h:1941:12: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87703 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #1 from Vittorio Zecca --- Still in trunk 270309 but requires optimization, at least -O1 to display the undefined behaviour. First time found while building gcc compiling dwarf2out.c
[Bug other/88790] No warning for misleading indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790 --- Comment #2 from Eric Gallager --- (In reply to Segher Boessenkool from comment #1) > (I couldn't add that cc:, Daniel doesn't have a bugzilla account yet). What about now?
[Bug c++/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #4 from bin cheng ---
In get_scaled_computation_cost_at, we have very big ratio between
bb_count/loop_count:
(gdb) p data->current_loop->latch->count
$50 = {static n_bits = 61, static max_count = 2305843009213693950, static
uninitialized_count = 2305843009213693951, m_val = 158483, m_quality =
profile_guessed_local}
(gdb) p gimple_bb(at)->count
$51 = {static n_bits = 61, static max_count = 2305843009213693950, static
uninitialized_count = 2305843009213693951, m_val = 1569139790, m_quality =
profile_guessed_local}
(gdb) p 1569139790 / 158483
$52 = 9900
(gdb) p cost
$53 = {cost = 20, complexity = 2, scratch = 1}
(gdb) p 19 * 9900
$54 = 188100
as a result, sum_cost soon reaches to overflow of infinite_cost. Shall we cap
the ratio so that it doesn't grow too quick? Of course, some benchmark data is
needed for this heuristic tuning.
Another problem is the generated binary has segment fault issue even compiled
O0:
$ ./g++ -O0 pr90078.cc -o a.out -ftemplate-depth=100 -ftime-report -g
-std=c++14
$ gdb --args ./a.out
Dump of assembler code for function main():
0x00400572 <+0>: push %rbp
0x00400573 <+1>: mov%rsp,%rbp
0x00400576 <+4>: sub$0x2625a020,%rsp
0x0040057d <+11>:lea-0x2625a020(%rbp),%rax
0x00400584 <+18>:mov%rax,%rdi
=> 0x00400587 <+21>:callq 0x4006c0 ::Tensor4()>
0x0040058c <+26>:lea-0x4c4b410(%rbp),%rax
0x00400593 <+33>:lea-0xe4e1c10(%rbp),%rdx
The segment fault happens at the callq instruction.
[Bug ipa/89693] [9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89693 --- Comment #9 from Arseny Solokha --- Can this PR be closed now?
[Bug c++/90108] New: ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108 Bug ID: 90108 Summary: ICE: Segmentation fault (in c_tree_chain_next) Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: GC Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-9.0.0-alpha20190414 snapshot (r270355), 8.3, 7.4, 6.3, 5.5 all ICE when compiling gcc/testsuite/c-c++-common/pr89933.c w/ --param ggc-min-heapsize=0: % g++-9.0.0-alpha20190414 --param ggc-min-heapsize=0 -c gcc/testsuite/c-c++-common/pr89933.c gcc/testsuite/c-c++-common/pr89933.c:5:71: internal compiler error: Segmentation fault 5 | typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__)); | ^ 0xf780df crash_signal /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/toplev.c:326 0xa3c507 c_tree_chain_next /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/c-family/c-common.h:1197 0xa3c507 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:110 0xa3d7a2 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:441 0xa3d6e9 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:420 0xa3d47a gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:336 0xcbaf04 ggc_mark_root_tab /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/ggc-common.c:77 0xcbb10c ggc_mark_roots() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/ggc-common.c:94 0xae542f ggc_collect() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/ggc-page.c:2201 0x91e775 c_parse_final_cleanups() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190414/work/gcc-9-20190414/gcc/cp/decl2.c:4819
[Bug c++/90107] New: rejects-valid on global-namespace-qualified variable declared after class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90107
Bug ID: 90107
Summary: rejects-valid on global-namespace-qualified variable
declared after class definition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC rejects these valid examples, producing a bogus "expected ';' after struct
definition" diagnostic:
struct A;
namespace N { extern A a; }
struct A {} ::N::a;
struct A;
struct B { static A a; };
struct A {} ::B::a;
(I just fixed a rejects-valid on the same cases in Clang.)
[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #2 from Frederico Lamberti Pissarra --- (In reply to Andrew Pinski from comment #1) > It is <0 when sqrt is called and it is due setting errno. Not a bug. Hu... interesting. But why the inefficient code?
[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- It is <0 when sqrt is called and it is due setting errno. Not a bug.
[Bug c/90106] New: builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
Bug ID: 90106
Summary: builtin sqrt() ignoring libm's sqrt call result
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fredericopissarra at gmail dot com
Target Milestone: ---
GCC 7.3 and 8.2 (from Ubuntu 18.04 and MinGW-w64) seems to generate wrong code
for sqrtf() -- and sqrt() -- for multiple platforms (tested under x86-64 and
ARM Arch64, gcc 7.3, and Arch32 with gcc 6.3). Try to compile this simple
function:
/* test.c */
#include
float f( float x ) { return sqrtf( x ); }
And I've got, for x86-64 using SSE:
# Compiled with gcc -O2 -S test.c
f:
pxor %xmm2,%xmm2
sqrtss %xmm0,%xmm1
ucomiss %xmm0,%xmm2
ja .L8
movaps %xmm1,%xmm0
ret
.L8:
subq $24,%rsp
movss %xmm1, 12(%rsp)# save xmm1 from sqrtss
call sqrtf@PLT
movss 12(%rsp),%xmm1 # restore xmm1.
addq $24,%rsp
movaps %xmm1,%xmm0 # use xmm1 anyway?!
ret
Notice, when 0 > x sqrt@PLT is called, but the result is ignored.
A similar code is created by GCC for ARM.
As expected, -ffast-math, creates:
f:
sqrtss %xmm0,%xmm0
ret
Which is correct.
My environment:
$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
$ gcc-8 --version
gcc-8 (Ubuntu 8.2.0-1ubuntu2~18.04) 8.2.0
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:6.3.1+svn253039-1build1) 6.3.1 20170620
$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04) 7.3.0
$ uname -srvp
Linux 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 --- Comment #3 from John Ericson --- Hmm, the GHC issue I meant to link I think is https://gitlab.haskell.org/ghc/ghc/issues/11042 . From the looks of it, I might have pasted the wrong URL anyways, but in any event GHC switched from Trac to (its own) GitLab, so the link would have eventually rotted regardless.
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Definitions added in r270372. I made a couple of tweaks to the original patch so that only mcontext_t and ucontext_t are public in the module, other than that, applied as-is.
[Bug d/90062] SPARC stack alignment is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Patch committed to r270372.
[Bug d/90060] libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Should be done in r270372, reopen if it's still a problem.
[Bug d/90060] libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060 --- Comment #2 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Mon Apr 15 20:32:50 2019 New Revision: 270372 URL: https://gcc.gnu.org/viewcvs?rev=270372&root=gcc&view=rev Log: PR d/90059 PR d/90060 PR d/90062 libphobos: Merge upstream druntime 70b9fea6 Backports fixes in the extern(C) bindings for the Solaris/SPARC port. Initial patch by Rainer Orth. Reviewed-on: https://github.com/dlang/druntime/pull/2555 Modified: trunk/libphobos/libdruntime/MERGE trunk/libphobos/libdruntime/core/sys/posix/ucontext.d trunk/libphobos/libdruntime/core/sys/solaris/link.d trunk/libphobos/libdruntime/core/thread.d
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 --- Comment #2 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Mon Apr 15 20:32:50 2019 New Revision: 270372 URL: https://gcc.gnu.org/viewcvs?rev=270372&root=gcc&view=rev Log: PR d/90059 PR d/90060 PR d/90062 libphobos: Merge upstream druntime 70b9fea6 Backports fixes in the extern(C) bindings for the Solaris/SPARC port. Initial patch by Rainer Orth. Reviewed-on: https://github.com/dlang/druntime/pull/2555 Modified: trunk/libphobos/libdruntime/MERGE trunk/libphobos/libdruntime/core/sys/posix/ucontext.d trunk/libphobos/libdruntime/core/sys/solaris/link.d trunk/libphobos/libdruntime/core/thread.d
[Bug d/90062] SPARC stack alignment is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Mon Apr 15 20:32:50 2019 New Revision: 270372 URL: https://gcc.gnu.org/viewcvs?rev=270372&root=gcc&view=rev Log: PR d/90059 PR d/90060 PR d/90062 libphobos: Merge upstream druntime 70b9fea6 Backports fixes in the extern(C) bindings for the Solaris/SPARC port. Initial patch by Rainer Orth. Reviewed-on: https://github.com/dlang/druntime/pull/2555 Modified: trunk/libphobos/libdruntime/MERGE trunk/libphobos/libdruntime/core/sys/posix/ucontext.d trunk/libphobos/libdruntime/core/sys/solaris/link.d trunk/libphobos/libdruntime/core/thread.d
[Bug c++/85890] [7 Regression] cc1plus runs out of memory in recursive Fibonacci computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85890 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed then.
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070 --- Comment #7 from Andrew Pinski --- (In reply to Segher Boessenkool from comment #6) > (How do you do this btw, remembering all PRs?! :-) ) No, I had remembered I had filed (seen in most other cases) a similar bug a long time ago (I don't remember when though) so I did a search as myself as a reporter and had in the summary, "float" and that is how I found it.
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
--- Comment #6 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #5)
> Oh that is PR 22326
Indeed it is. And your conclusion there ("we need some pass that does
this properly", instead of the current thing during expand) still holds,
too. (How do you do this btw, remembering all PRs?! :-) )
[Bug c++/90105] New: std::forward_list::sort() is not "stable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105 Bug ID: 90105 Summary: std::forward_list::sort() is not "stable" Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stoyanovmk at ornl dot gov Target Milestone: --- Created attachment 46175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46175&action=edit Small example to reproduce the issue From: https://en.cppreference.com/w/cpp/container/forward_list/sort "Note: This function also differs from std::sort in that it does not require the element type of the forward_list to be swappable, preserves the values of all iterators, and performs a stable sort." Output of the attached sample program: ``` List before sort: a 1 b 2 c 1 d 0 List after sort: d 0 c 1 a 1 b 2 ``` Note that (a, 1) comes before (c, 1), but after the sort the order is reversed. PS: Example used gcc 7.3.0 under Ubutnu 18.04, but the behavior is pretty consistent across versions, including 6.3 and 8.0.
[Bug c++/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078 --- Comment #3 from Walter Landry --- (In reply to Martin Liška from comment #2) > I'm adding the pass maintainer to CC. > @Walter: Do you have an account so that you'll be able to propose the patch > to GCC patches mailing list? The only account I have with GCC is bugzilla. I have never posted anything to gcc-patches, but long ago I sent some messages to g...@gcc.gnu.org. Let me know what you want me to do.
[Bug target/90096] Misleading option hint for AVX intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90096 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 46174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46174&action=edit gcc9-pr90096.patch Untested fix.
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
--- Comment #5 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #4)
> float f(float x, float y) { return 5.0*x + y; }
>
> it does not (and AFAICS it gives identical results here, too, even without
> -ffast-math, which makes no difference currently):
Oh that is PR 22326
[Bug gcov-profile/90104] New: [GCOV] Wrong coverage for variable arguments function call statement while the function is inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90104
Bug ID: 90104
Summary: [GCOV] Wrong coverage for variable arguments function
call statement while the function is inline function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --enable-languages=c,c++
--disable-multilib --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 9.0.1 20190414 (experimental) (GCC)
$ cat small.c
#include
extern void abort (void);
long x = 0, y = 0;
inline void __attribute__((always_inline))
f1i (va_list ap)
{
x = va_arg (ap, double);
x += va_arg (ap, long);
}
void f4 (int i, ...)
{
va_list ap;
va_start (ap, i);
switch (i)
{
case 4:
y = va_arg (ap, double);
break;
case 5:
y = va_arg (ap, double);
y += va_arg (ap, double);
break;
default:
; // abort ();
}
f1i (ap);
va_end (ap);
}
int main ()
{
f4 (4, 6.0, 9.0, 16L, 18.0);
return 0;
}
$ rm small.g*; gcc -O0 --coverage small.c -w; ./a.out; gcov small.c; cat
small.c.gcov
File 'small.c'
Lines executed:78.95% of 19
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:#include
-:2:
-:3:extern void abort (void);
-:4:long x = 0, y = 0;
-:5:
-:6:inline void __attribute__((always_inline))
-:7:f1i (va_list ap)
-:8:{
2:9: x = va_arg (ap, double);
1: 10: x += va_arg (ap, long);
1: 11:}
-: 12:
1: 13:void f4 (int i, ...)
-: 14:{
-: 15: va_list ap;
-: 16:
1: 17: va_start (ap, i);
1: 18: switch (i)
-: 19: {
1: 20:case 4:
1: 21: y = va_arg (ap, double);
1: 22: break;
#: 23:case 5:
#: 24: y = va_arg (ap, double);
#: 25: y += va_arg (ap, double);
#: 26: break;
1: 27:default:
-: 28: ; // abort ();
-: 29: }
-: 30: f1i (ap);
1: 31: va_end (ap);
1: 32:}
-: 33:
1: 34:int main ()
-: 35:{
1: 36: f4 (4, 6.0, 9.0, 16L, 18.0);
1: 37: return 0;
-: 38:}
Line #9 is wrongly marked as executed twice.
While Line #28 is removed, the result is correct as follows:
$ gcc -O0 --coverage small.c -w; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:70.00% of 20
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:#include
-:2:
-:3:extern void abort (void);
-:4:long x = 0, y = 0;
-:5:
-:6:inline void __attribute__((always_inline))
-:7:f1i (va_list ap)
-:8:{
1:9: x = va_arg (ap, double);
1: 10: x += va_arg (ap, long);
1: 11:}
-: 12:
1: 13:void f4 (int i, ...)
-: 14:{
-: 15: va_list ap;
-: 16:
1: 17: va_start (ap, i);
1: 18: switch (i)
-: 19: {
1: 20:case 4:
1: 21: y = va_arg (ap, double);
1: 22: break;
#: 23:case 5:
#: 24: y = va_arg (ap, double);
#: 25: y += va_arg (ap, double);
#: 26: break;
#: 27:default:
#: 28: abort ();
-: 29: }
-: 30: f1i (ap);
1: 31: va_end (ap);
1: 32:}
-: 33:
1: 34:int main ()
-: 35:{
1: 36: f4 (4, 6.0, 9.0, 16L, 18.0);
1: 37: return 0;
-: 38:}
[Bug middle-end/90095] [9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 --- Comment #2 from Jakub Jelinek --- Created attachment 46173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46173&action=edit gcc9-pr90095.patch Untested fix.
[Bug target/90103] New: ICE building Glibc's e_atan2f.c with -O2 -mcpu=hs38_linux -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90103 Bug ID: 90103 Summary: ICE building Glibc's e_atan2f.c with -O2 -mcpu=hs38_linux -frounding-math Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: abrodkin at synopsys dot com Target Milestone: --- Created attachment 46172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46172&action=edit Preprocesssed input file # arc-unknown-linux-gnu-gcc -mcpu=hs38_linux e_atan2f.i -c -O2 -frounding-math ../sysdeps/ieee754/flt-32/e_atan2f.c: In function '__ieee754_atan2f': ../sysdeps/ieee754/flt-32/e_atan2f.c:93:1: error: unrecognizable insn: } ^ (insn 112 111 113 25 (set (reg/v:SF 172 [ ]) (fma:SF (const_double:SF 3.0e+0 [0x0.cp+2]) (const_double:SF 7.85398185253143310546875e-1 [0x0.c90fdbp+0]) (reg:SF 58 r58))) "../sysdeps/ieee754/flt-32/e_atan2f.c":61 -1 (nil)) during RTL pass: vregs ../sysdeps/ieee754/flt-32/e_atan2f.c:93:1: internal compiler error: in extract_insn, at recog.c:2304 0x55ed94 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /.build/arc-unknown-linux-gnu/src/gcc/gcc/rtl-error.c:108 0x55edb0 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /.build/arc-unknown-linux-gnu/src/gcc/gcc/rtl-error.c:116 0x9aa5c7 extract_insn(rtx_insn*) /.build/arc-unknown-linux-gnu/src/gcc/gcc/recog.c:2304 0x7c258d instantiate_virtual_regs_in_insn /.build/arc-unknown-linux-gnu/src/gcc/gcc/function.c:1599 0x7c258d instantiate_virtual_regs /.build/arc-unknown-linux-gnu/src/gcc/gcc/function.c:1969 0x7c258d execute /.build/arc-unknown-linux-gnu/src/gcc/gcc/function.c:2018
[Bug ipa/89693] [9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89693 --- Comment #8 from Martin Jambor --- Author: jamborm Date: Mon Apr 15 14:31:57 2019 New Revision: 270371 URL: https://gcc.gnu.org/viewcvs?rev=270371&root=gcc&view=rev Log: Reorganize cgraph_node::clone_of_p 2019-04-15 Martin Jambor PR ipa/89693 * cgraph.c (clone_of_p): Loop over clone chain for each step in the thunk chain. testsuite/ * g++.dg/ipa/pr89693.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ipa/pr89693.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/cgraph.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/90081] stdint constant macros evaluating to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081 --- Comment #5 from Guy Perfect --- (In reply to Harald van Dijk from comment #4) That was my line of thinking: supplying a cast in the macro. Even in the case of negative values being cast to unsigned types, the language spec provides a rule for that, so the behavior is defined independent of the implementation: "[... T]he value is converted to unsigned by adding to it one greater than the largest number that can be represented in the unsigned integer type." and "In a two's-complement representation, there is no actual change in the bit pattern except filling the high-order bits with copies of the sign bit if the unsigned integer has greater size." I think the ticket was marked "resolved invalid" prematurely, as there's clearly a meaningful problem and a meaningful solution.
[Bug fortran/90069] Polymorphic Return Type Memory Leak Without Intermediate Variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90069 --- Comment #2 from Brad Richardson --- (In reply to Dominique d'Humieres from comment #1) > Confirmed from at least 4.8 up to trunk (9.0). Why is it not a duplicate of > pr90072? Because pr90072 occurs even with an intermediate variable.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #48 from Bernd Edlinger ---
(In reply to Florian Weimer from comment #47)
> (In reply to Bernd Edlinger from comment #43)
> > does anybody know what is the Ada and/or D syntax for that?
>
> Syntax for what?
I mean the Ada and D equivalent of
#pragma GCC target ("general-regs-only")
and/or
__attribute__((target("general-regs-only")))
>
> I fear we need eagerly load all vector registers before calling the
> personality routine.
I am afraid the unwind handler will probably not know which coprocessor
registers exist before the unwind code hits them.
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 Rainer Orth changed: What|Removed |Added Attachment #46161|0 |1 is obsolete|| Attachment #46162|0 |1 is obsolete|| --- Comment #4 from Rainer Orth --- Created attachment 46171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46171&action=edit Revised working patch
[Bug tree-optimization/56049] [7/8/9 Regression] Simplification to constants not done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 --- Comment #23 from Richard Biener --- So we are _nearly_ there on trunk. LIM has improved up to the point the only blocker is mismatching alias-sets in mem_ref_hasher::equal and the case in question for this PR is even handled correctly because refs arrive in the correct order and the one we'd chose has the ref-all case we'd have to canonicalize to anyways. So the following works (and can be slightly enhanced). Index: gcc/tree-ssa-loop-im.c === --- gcc/tree-ssa-loop-im.c (revision 270366) +++ gcc/tree-ssa-loop-im.c (working copy) @@ -178,7 +178,15 @@ mem_ref_hasher::equal (const im_mem_ref && known_eq (mem1->mem.size, obj2->size) && known_eq (mem1->mem.max_size, obj2->max_size) && mem1->mem.volatile_p == obj2->volatile_p - && mem1->mem.ref_alias_set == obj2->ref_alias_set + && (mem1->mem.ref_alias_set == obj2->ref_alias_set + /* We are not canonicalizing alias-sets but for the + special-case we didn't canonicalize yet and the + incoming ref is a alias-set zero MEM we pick + the correct one already. */ + || (!mem1->ref_canonical + && (TREE_CODE (obj2->ref) == MEM_REF + || TREE_CODE (obj2->ref) == TARGET_MEM_REF) + && obj2->ref_alias_set == 0)) && types_compatible_p (TREE_TYPE (mem1->mem.ref), TREE_TYPE (obj2->ref))); else
[Bug c++/90102] New: Incorrect ambiguous overload with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
Bug ID: 90102
Summary: Incorrect ambiguous overload with _GLIBCXX_DEBUG
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 46170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46170&action=edit
Preprocessed source code
The following code fails to compile with the debugging version of
containers. It's fine with the regular version.
Problem could be in either compiler or library. Assigning to c++ component for
now.
$ cat bbb.C
#include
class Foo {
public:
template().clear())>
operator Cont () const { return {}; }
};
std::vector bar() {
return static_cast> (Foo());
}
$ /usr/local/products/gcc/8.2.0/bin/g++ -c bbb.C
[Nothing]
$ /usr/local/products/gcc/8.2.0/bin/g++ -D_GLIBCXX_DEBUG -c bbb.C
bbb.C: In function ‘std::__debug::vector bar()’:
bbb.C:11:46: error: call of overloaded ‘vector(Foo)’ is ambiguous
return static_cast> (Foo());
^
In file included from
/usr/local/products/gcc/8.2.0/include/c++/8.2.0/vector:73,
from bbb.C:1:
/usr/local/products/gcc/8.2.0/include/c++/8.2.0/debug/vector:214:7: note:
candidate: ‘std::__debug::vector<_Tp, _Allocator>::vector(const _Base&) [with
_Tp = int; _Allocator = std::allocator; std::__debug::vector<_Tp,
_Allocator>::_Base = std::__cxx1998::vector >]’
vector(const _Base& __x)
^~
/usr/local/products/gcc/8.2.0/include/c++/8.2.0/debug/vector:196:7: note:
candidate: ‘std::__debug::vector<_Tp,
_Allocator>::vector(std::__debug::vector<_Tp, _Allocator>&&) [with _Tp = int;
_Allocator = std::allocator]’
vector(vector&&) = default;
^~
/usr/local/products/gcc/8.2.0/include/c++/8.2.0/debug/vector:195:7: note:
candidate: ‘std::__debug::vector<_Tp, _Allocator>::vector(const
std::__debug::vector<_Tp, _Allocator>&) [with _Tp = int; _Allocator =
std::allocator]’
vector(const vector&) = default;
^~
$ /usr/local/products/gcc/8.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/8.2.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/8.2.0/lib/gcc/x86_64-suse-linux/8.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-8.2.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/8.2.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.30/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.30/bin/ld.bfd
--enable-threads=posix --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=pool x86_64-suse-linux
Thread model: posix
gcc version 8.2.0 (GCC)
[Bug c++/90101] New: [P0732]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90101
Bug ID: 90101
Summary: [P0732]
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
Hi,
Compiling the code provided below with the following options produces an error:
"-std=c++2a -Wall -Wextra"
```
template
struct A;
template typename List>
struct A> {};
template typename List, auto V>
struct A> {};
template
struct B {};
// works
A> a1;
// error
struct X {
int value;
};
A> a2;
```
Error:
:20:12: error: aggregate 'A > a2' has incomplete type and
cannot be defined
20 | A> a2;
|^~
See also: https://godbolt.org/z/QSRjFb
Best
Mat
[Bug c++/90100] New: [P0732] Cannot write a type-trait matching non-type class template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90100
Bug ID: 90100
Summary: [P0732] Cannot write a type-trait matching non-type
class template parameters
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
Hi,
Compiling the code provided below with the following options produces an error:
"-std=c++2a -Wall -Wextra"
```
template
inline constexpr bool is_nontype_list = false;
template typename T, auto... NonTypes>
inline constexpr bool is_nontype_list> = true;
template
concept bool NonTypeList = is_nontype_list;
// works
template
struct A {};
static_assert(is_nontype_list>);
// fails
struct X {
int v;
};
static_assert(is_nontype_list>);
```
See also: https://godbolt.org/z/56PLu-
Best
Mat
[Bug c++/90099] New: [P0732] Partial specialization of a class template with variadic parameter pack fails after adding non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90099
Bug ID: 90099
Summary: [P0732] Partial specialization of a class template
with variadic parameter pack fails after adding
non-type template parameter
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
Hi,
Compiling the code provided below with the following options produces an error:
"-std=c++2a -Wall -Wextra"
```
struct Unit {
int value;
// auto operator<=>(const Unit&) = default;
};
template
struct X {};
template
struct X {};
```
Error:
:10:8: error: template argument '((Unit*)(void)0)->Unit::__ct_comp
(((const Unit)U))' involves template parameter(s)
10 | struct X {};
|^~~~
See also here:
https://godbolt.org/z/OdmHCf
Best
Mat
[Bug c++/90098] New: [P0732] Partial specialization of a class template with variadic parameter pack fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90098
Bug ID: 90098
Summary: [P0732] Partial specialization of a class template
with variadic parameter pack fails
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
Hi,
Compiling the code provided below with the following options produces an error:
"-std=c++2a -Wall -Wextra"
```
// works
template
struct X {};
template
struct X {};
// works
template
struct Y {};
template
struct Y {};
// error
struct A {
int value;
// auto operator<=>(const A&) = default;
};
template
struct Z {};
template
struct Z {};
```
Error:
:25:8: error: partial specialization 'struct
Z<((A*)(void)0)->A::__ct_comp (((const A)V)), (const A)Rest ...>' is not more
specialized than [-fpermissive]
25 | struct Z {};
|^
:22:8: note: primary template 'template struct Z'
22 | struct Z {};
|^
:25:8: error: template argument '((A*)(void)0)->A::__ct_comp (((const
A)V))' involves template parameter(s)
25 | struct Z {};
|^
:25:8: error: template argument '(const A)Rest' involves template
parameter(s)
See also: https://godbolt.org/z/G96q1_.
Best
Mat
[Bug c++/90097] New: [P0732] Error while comparing 2 non-type parameters in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90097
Bug ID: 90097
Summary: [P0732] Error while comparing 2 non-type parameters in
constraints
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
Hi,
Compiling the code provided below with the following options produces an error:
"-std=c++2a -fconcepts -Wall -Wextra"
```
struct B {
int value;
// auto operator<=>(const base_dimension&) = default;
friend constexpr bool operator==(const B& lhs, const B& rhs) noexcept {
return lhs.value == rhs.value; }
};
//works
template
requires (i1 == i2)
struct A {};
// works
template
struct C {
static_assert(b1 == b2);
};
// error
template
requires (b1 == b2)
struct D {};
```
Error:
:24:16: error: constraint 'operator==(((const B)b1), ((const B)b2))',
uses overloaded operator
24 | requires (b1 == b2)
|^~
I am not sure what is the offcial suport -fconcepts and if that problem can be
ignored for now or not so I decided to report it anyway ;-)
See also here: https://godbolt.org/z/PLkvVm.
Thanks
Mat
[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055 --- Comment #4 from Richard Biener --- (In reply to Andrew Pinski from comment #3) > (In reply to Martin Liška from comment #2) > > Fixed on trunk with r250959 which is: > > > > 364bc5b93b76cf88(08 Aug 2017 14:09): [took: 2.844s] result: OK > > sum: 0. > > SVN revision: 250959 > > Author: amker > > * doc/invoke.texi: Document -ftree-loop-distribution for O3. > > * opts.c (default_options_table): Add OPT_ftree_loop_distribution. > > > > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250959 > > 138bc75d-0d04-0410-961f-82ee72b054a4 > > > > Using: > > gcc pr90055.c -O3 -ffast-math -march=haswell -mtune=haswell > > -fno-tree-loop-distribution > > > > it disappeared in r253934: > > > > Author: hubicka > > * x86-tune-costs.h (core_cost): Fix div, move and sqrt latencies. > > Those look like they are all would cause the issue to go latent. > > > > > and it started with r238033. > > This one does it might be the real cause of the issue. Nope, it just does less peeling for gaps.
[Bug tree-optimization/90071] [7/8 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] internal |[7/8 Regression] internal |compiler error: SSA |compiler error: SSA |corruption |corruption Known to fail||7.4.0, 8.3.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug debug/90074] wrong debug info at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90074 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to work||9.0 Version|unknown |9.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed on trunk.
[Bug debug/90074] wrong debug info at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90074 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Apr 15 12:26:11 2019 New Revision: 270370 URL: https://gcc.gnu.org/viewcvs?rev=270370&root=gcc&view=rev Log: 2019-04-15 Richard Biener PR debug/90074 * tree-loop-distribution.c (destroy_loop): Preserve correct debug info. * gcc.dg/guality/pr90074.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/guality/pr90074.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #47 from Florian Weimer --- (In reply to Bernd Edlinger from comment #43) > does anybody know what is the Ada and/or D syntax for that? Syntax for what? I fear we need eagerly load all vector registers before calling the personality routine.
[Bug c++/89940] [7/8 Regression] Template substitution causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89940 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||aoliva at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r241425 and was fixed on trunk in r267251.
[Bug ipa/89693] [9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89693 --- Comment #7 from Martin Jambor --- Te commit did not appear here because I made a pasto in the commit message, the fix landed as: URL: https://gcc.gnu.org/viewcvs?rev=270364&root=gcc&view=rev Log: Reorganize cgraph_node::clone_of_p 2019-04-15 Martin Jambor PR ipa/pr89693 * cgraph.c (clone_of_p): Loop over clone chain for each step in the thunk chain. testsuite/ * g++.dg/ipa/pr89693.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr89693.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/89693] [9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89693 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor --- Fixed on trunk, I am in the process of testing a straightforward backport to GCC 8.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 --- Comment #10 from Marc Glisse --- "Forward progress [intro.progress] The implementation may assume that any thread will eventually do one of the following: (1.1) — terminate, (1.2) — make a call to a library I/O function, (1.3) — perform an access through a volatile glvalue, or (1.4) — perform a synchronization operation or an atomic operation. [Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note]"
[Bug target/90096] Misleading option hint for AVX intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90096 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-4-15 CC||hjl.tools at gmail dot com, ||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Host||x86_64-linux-gnu Target Milestone|--- |10.0 Severity|normal |enhancement
[Bug target/90096] New: Misleading option hint for AVX intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90096
Bug ID: 90096
Summary: Misleading option hint for AVX intrinsics
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
I see following misleading hint for:
$ cat /tmp/avx512.c
#include
volatile __m512i x1, x2;
volatile __mmask64 m64;
int foo(int i) {
x1 = _mm512_gf2p8affineinv_epi64_epi8(x1, x2, 3);
return 4;
}
$ ./xgcc -B. /tmp/avx512.c -c
In file included from ./include/immintrin.h:117,
from ./include/x86intrin.h:32,
from /tmp/avx512.c:1:
/tmp/avx512.c: In function ‘foo’:
/tmp/avx512.c:6:10: error: ‘__builtin_ia32_vgf2p8affineinvqb_v64qi’ needs isa
option -m32 -mgfni -mavx512f
6 | x1 = _mm512_gf2p8affineinv_epi64_epi8(x1, x2, 3);
| ^~~~
Where '-m32' is not needed of course:
$ ./xgcc -B. /tmp/avx512.c -c -mgfni -mavx512f
[OK]
It's caused by:
gcc/config/i386/gfniintrin.h-__attribute__((__gnu_inline__, __always_inline__,
__artificial__))
gcc/config/i386/gfniintrin.h:_mm512_gf2p8affineinv_epi64_epi8 (__m512i __A,
__m512i __B, const int __C)
gcc/config/i386/gfniintrin.h-{
gcc/config/i386/gfniintrin.h- return (__m512i)
__builtin_ia32_vgf2p8affineinvqb_v64qi ((__v64qi) __A,
gcc/config/i386/gfniintrin.h-
(__v64qi) __B, __C);
gcc/config/i386/gfniintrin.h-}
gcc/config/i386/gfniintrin.h-
Is it something we can improve?
Clang for instance prints:
clang /tmp/avx512.c
/tmp/avx512.c:6:10: error: '__builtin_ia32_vgf2p8affineinvqb_v64qi' needs
target feature avx512bw,gfni
x1 = _mm512_gf2p8affineinv_epi64_epi8(x1, x2, 3);
^
/usr/lib64/clang/8.0.0/include/gfniintrin.h:64:12: note: expanded from macro
'_mm512_gf2p8affineinv_epi64_epi8'
(__m512i)__builtin_ia32_vgf2p8affineinvqb_v64qi((__v64qi)(__m512i)(A),
\
^
1 error generated.
Apparently they use macros instead of gnu_inline attributes.
[Bug tree-optimization/90071] [7/8/9 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Apr 15 11:59:02 2019 New Revision: 270369 URL: https://gcc.gnu.org/viewcvs?rev=270369&root=gcc&view=rev Log: 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr90071.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug middle-end/90056] 548.exchange2_r regressions on AMD Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90056 --- Comment #1 from Martin Liška --- Created attachment 46169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46169&action=edit perf annotate - Ofast native vs. Ofast native PGO I'm attaching HTML and txt perf annotate for Ofast native and Ofast native PGO builds. As seen, it's still the same story. There's a big register pressure that leads to spilling of some of the induction variables. For these builds, the most significant difference is: GOOD: : if(block(row, 4, i4) <= 0) cycle 0.00 :41c660: mov(%r9),%r12d 1.99 :41c663: mov%r11d,0x80(%rsp) 0.11 :41c66b: mov%r11d,%edx 0.02 :41c66e: test %r12d,%r12d 0.15 :41c671: jg 41c7b0 <__brute_force_MOD_digits_2+0xe00> 0.01 :41c677: inc%r11 0.64 :41c67a: add$0x144,%r9 0.13 :41c681: add$0x144,%r8 0.05 :41c688: add$0x144,%r10 : do i4 = l(4), u(4) 0.15 :41c68f: cmp%r11d,0x6c(%rsp) 2.39 :41c694: jge41c660 <__brute_force_MOD_digits_2+0xcb0> 0.00 :41c696: mov0x168(%rsp),%r10 0.55 :41c69e: mov0x170(%rsp),%r9 0.08 :41c6a6: mov0x178(%rsp),%r11 0.05 :41c6ae: mov0x180(%rsp),%r8 : block(row, 4:9, i3) = block(row, 4:9, i3) + 10 BAD: : if(block(row, 4, i4) <= 0) cycle 0.05 :41a8b0: mov(%r11),%edi 0.78 :41a8b3: mov%r10d,0x84(%rsp) 0.04 :41a8bb: mov%r10d,%r13d 0.01 :41a8be: test %edi,%edi 0.26 :41a8c0: jg 41aa10 <__brute_force_MOD_digits_2+0x1210> 0.44 :41a8c6: addq $0x144,0x48(%rsp) 4.04 :41a8cf: addq $0x144,0x58(%rsp) 1.31 :41a8d8: inc%r10 0.02 :41a8db: add$0x144,%r11 : do i4 = l(4), u(4) 0.01 :41a8e2: cmp%r10d,0x88(%rsp) 0.25 :41a8ea: jge41a8b0 <__brute_force_MOD_digits_2+0x10b0> : block(row, 4:9, i3) = block(row, 4:9, i3) + 10 0.03 :41a8ec: mov0xd0(%rsp),%r15 0.27 :41a8f4: addl $0xa,-0xdc(%r15) 0.20 :41a8fc: addl $0xa,-0xb8(%r15) 0.01 :41a904: addl $0xa,-0x94(%r15) 0.07 :41a90c: addl $0xa,-0x70(%r15) 0.05 :41a911: addl $0xa,-0x4c(%r15) 0.06 :41a916: addl $0xa,-0x28(%r15) The benchmark is quite unpredictable, I'm leaving that for now.
[Bug tree-optimization/90095] [9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.4 |9.0 Summary|[8/9 Regression] wrong code |[9 Regression] wrong code |with -Os -fno-tree-bit-ccp |with -Os -fno-tree-bit-ccp
[Bug tree-optimization/90095] [8/9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-15 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |8.4 Summary|[9 Regression] wrong code |[8/9 Regression] wrong code |with -Os -fno-tree-bit-ccp |with -Os -fno-tree-bit-ccp Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with my r259649. I'll have a look.
[Bug d/90063] druntime DSO first assertion fails on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Rainer Orth --- (In reply to ibuclaw from comment #1) > After others have been committed, can you post a new stacktrace for this? After the move to gcc/sections, rt/bss_section.c is gone and so are both rt_get_bss_start and the assert. I've bootstrapped on sparc-sun-solaris2.11 with the additonal big-endian and Solaris/SPARC patches and the problem is gone.
[Bug rtl-optimization/89794] combine incorrectly forwards register value through auto-inc operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Mon Apr 15 11:33:29 2019 New Revision: 270368 URL: https://gcc.gnu.org/viewcvs?rev=270368&root=gcc&view=rev Log: combine: Count auto_inc properly (PR89794) The code that checks if an auto-increment from i0 or i1 is not lost is a bit shaky. The code to check the same for i2 is non-existent, and cannot be implemented in a similar way at all. So, this patch counts all auto-increments, and makes sure we end up with the same number as we started with. This works because we still have a check that we will not duplicate any. We should do this some better way, but not while we are in stage 4. PR rtl-optimization/89794 * combine.c (count_auto_inc): New function. (try_combine): Count how many auto_inc expressions there were in the original instructions. Ensure we have the same number in the new instructions. Remove the code that tried to ensure auto_inc side effects on i1 and i0 are not lost. gcc/testsuite/ PR rtl-optimization/89794 * gcc.dg/torture/pr89794.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr89794.c Modified: trunk/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/90095] New: [9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 Bug ID: 90095 Summary: [9 Regression] wrong code with -Os -fno-tree-bit-ccp Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: i686-pc-linux-gnu Created attachment 46168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46168&action=edit reduced testcase Output: $ i686-pc-linux-gnu-gcc -Os -fno-tree-bit-ccp $ ./a.out Aborted The multiplication does not overflow, but the generated code indicates it overflows. $ i686-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-i686/bin/i686-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-270358-checking-yes-rtl-df-extra-i686/bin/../libexec/gcc/i686-pc-linux-gnu/9.0.1/lto-wrapper Target: i686-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=i686-pc-linux-gnu --with-ld=/usr/bin/i686-pc-linux-gnu-ld --with-as=/usr/bin/i686-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-270358-checking-yes-rtl-df-extra-i686 Thread model: posix gcc version 9.0.1 20190415 (experimental) (GCC)
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-gnu-linux, |powerpc*-*-*
|powerpc64-gnu-linux |
Host|powerpc64le-gnu-linux, |
|powerpc64-gnu-linux |
Build|powerpc64le-gnu-linux, |
|powerpc64-gnu-linux |
--- Comment #4 from Segher Boessenkool ---
You'll have a crossing anyway (it is y+5*x with x an integer and y a float),
but a single fma is faster than doing the mul as integer, almost everywhere.
When we write e.g.
float f(float x) { return 5.0 * x; }
GCC is smart enough to do the mul in single precision (although C says it is
double precision, and only later rounded to SP, the result is identical)"
addis 9,2,.LC0@toc@ha
lfs 0,.LC0@toc@l(9)
fmuls 1,1,0
blr
but for
float f(float x, float y) { return 5.0*x + y; }
it does not (and AFAICS it gives identical results here, too, even without
-ffast-math, which makes no difference currently):
addis 9,2,.LC1@toc@ha
lfd 0,.LC1@toc@l(9)
fmadd 1,1,0,2
frsp 1,1
blr
[Bug target/90094] New: better handling of x == LONG_MIN on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094
Bug ID: 90094
Summary: better handling of x == LONG_MIN on x86-64
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Compile the following on x86-64:
unsigned f(long a)
{
return a == LONG_MIN;
}
The result for -O3 is:
f: movabs $0x8000,%rax
cmp%rax,%rdi
sete %al
movzbl %al,%eax
retq
With -Os it looks like this:
f: mov$0x1,%eax
shl$0x3f,%rax
cmp%rax,%rdi
sete %al
movzbl %al,%eax
retq
I think for both optimization directions the code should be compiled as if for
this:
unsigned f(long a)
{
long r;
return __builtin_sub_overflow(a, 1, &r);
}
This compiled to
f: xor%eax,%eax
add$0x,%rdi
seto %al
retq
This should be faster and is definitely shorter than even the -Os version.
For 32-bit x86 the problem doesn't exist is this form, I think. But it might
apply to some RISC targets as well.
[Bug c/90081] stdint constant macros evaluating to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #4 from Harald van Dijk --- (In reply to Martin Sebor from comment #3) > UINT8_C(-5) isn't valid but expanding the macros to their arguments isn't > conforming either. C11 DR #456 suggests compiler magic is necessary to make > the macros correct: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_456 (Also see > C99 DR 209: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_209.htm). It doesn't seem like compiler magic is really needed: #define UINT8_C(x) ((__uint8_t) +(x##U)) This works correctly even in #if expressions because of the replacement of __uint8_t by 0.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #9 from Richard Biener ---
clang doesn't optimize the corresponding C testcase
struct Foo {
struct Foo *next;
};
void release(struct Foo *next) {
struct Foo *tmp = 0;
for (struct Foo *it = next; it; it = tmp) {
tmp = it->next;
}
}
which means it needs to have a way in the IL to annotate loops as
terminating.
Does the C++ rule apply to all cycles or just to "loops"? (thinking
of goto, recursion, etc.)
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 --- Comment #8 from Richard Biener --- So it's legal to remove the classical "halt CPU" while (1);? Interesting... Does this apply to C++ only? I presume for libstdc++ we could add a #pragma GCC loop finite which tells GCC it can assume the loop eventually terminates.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 --- Comment #7 from Gareth Lloyd --- To give extra context, this optimization is desirable when using pmr::monotonic_buffer_resource. After de-virtualization and inlining it is likely for node based containers with trivially destructible internal types will end up with empty loops in their destructors.
[Bug rtl-optimization/90082] [9 Regression] ICE in delete_unmarked_insns, at dce.c:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90082 --- Comment #3 from Jakub Jelinek --- Created attachment 46167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46167&action=edit gcc9-pr90082.patch Untested fix.
[Bug rtl-optimization/90082] [9 Regression] ICE in delete_unmarked_insns, at dce.c:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90082
--- Comment #2 from Jakub Jelinek ---
The problem is that in this case can_alter_cfg is false (fast DCE), and we have
a
(call_insn/u 27 25 38 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("__mulvsi3") [flags 0x41]) [0 S1 A8])
(const_int 0 [0]))) "pr90082.c":7:28 677 {*call_value}
(expr_list:REG_DEAD (reg:SI 5 di)
(expr_list:REG_DEAD (reg:SI 4 si)
(expr_list:REG_UNUSED (reg:SI 0 ax)
(nil
(expr_list (use (reg:SI 4 si))
(expr_list (use (reg:SI 5 di))
(nil
call that DCE would like to remove. The assert is that we really don't remove
unreachable blocks etc. when we don't want to alter the cfg; the call is
nothrow_insn_p and so we think it is fine to remove it, but it isn't if we
can't modify the cfg - there are EDGE_ABNORMAL edges after the call.
[Bug ipa/88936] [7/8 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] |[7/8 Regression] -fipa-pta |-fipa-pta breaks bash |breaks bash (incorrect |(incorrect optimisation of |optimisation of recursive |recursive static function) |static function) Known to fail|9.0 | --- Comment #15 from Richard Biener --- Fixed on trunk sofar.
[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936 --- Comment #14 from Richard Biener --- Author: rguenth Date: Mon Apr 15 10:09:08 2019 New Revision: 270366 URL: https://gcc.gnu.org/viewcvs?rev=270366&root=gcc&view=rev Log: 2019-04-15 Richard Biener PR ipa/88936 * tree.h (auto_var_p): Declare. * tree.c (auto_var_p): New function, split out from ... (auto_var_in_fn_p): ... here. * tree-ssa-structalias.c (struct variable_info): Add shadow_var_uid member. (new_var_info): Initialize it. (set_uids_in_ptset): Also set the shadow variable uid if required. (ipa_pta_execute): Postprocess points-to solutions assigning shadow variable uids for locals that may reach their containing function recursively. * tree-ssa-ccp.c (fold_builtin_alloca_with_align): Do not assert but instead check whether the points-to solution is a singleton. * gcc.dg/torture/pr88936-1.c: New testcase. * gcc.dg/torture/pr88936-2.c: Likewise. * gcc.dg/torture/pr88936-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr88936-1.c trunk/gcc/testsuite/gcc.dg/torture/pr88936-2.c trunk/gcc/testsuite/gcc.dg/torture/pr88936-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug fortran/90093] New: Extended C interop: optional argument incorrectly identified as PRESENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90093 Bug ID: 90093 Summary: Extended C interop: optional argument incorrectly identified as PRESENT Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Bader at lrz dot de Target Milestone: --- Created attachment 46166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46166&action=edit UNIX archive with test case The attached test code can be compiled with gcc -c optional_02_pos.c gfortran optional_02_pos.f90 optional_02_pos.o and produces the output FAIL 2 T T T The cause of this is that the call of the procedure from C with NULL as first argument is incorrectly treated. This appears to be a regression of the most recent fixes for the C descriptor.
[Bug debug/90074] wrong debug info at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90074 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-15 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Generally loop optimizers are bad when handling debug info, most of the time dropping them on the floor rather than changing them to resets. In this particular case it's loop distribution: @@ -16,33 +25,7 @@ # DEBUG i => 0 # DEBUG BEGIN_STMT # DEBUG i => 0 - - [local count: 719407024]: - # i_14 = PHI <0(2), i_8(5)> - # ivtmp_4 = PHI <7(2), ivtmp_1(5)> - # DEBUG c => NULL - # DEBUG i => NULL - # DEBUG i => i_14 - # DEBUG c => NULL - # DEBUG c => 0 - # DEBUG BEGIN_STMT - b[i_14][0] = 0; - # DEBUG c => 1 - # DEBUG c => NULL - # DEBUG c => 1 - i_8 = i_14 + 1; - # DEBUG i => i_8 - # DEBUG i => i_8 - ivtmp_1 = ivtmp_4 - 1; - if (ivtmp_1 != 0) -goto ; [0.00%] - else -goto ; [100.00%] - - [local count: 0]: - goto ; [100.00%] - - [local count: 719407023]: + __builtin_memset (&b, 0, 14); # DEBUG BEGIN_STMT optimize_me_not (); it's not "easy" to fix things up here, but loop-distribution uses delete_basic_block and edge redirection which bypasses CFG cleanup ability to eventually handle this better. I have a patch.
[Bug middle-end/88587] ICE in expand_debug_locations, at cfgexpand.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587 --- Comment #16 from Martin Liška --- Author: marxin Date: Mon Apr 15 08:53:24 2019 New Revision: 270365 URL: https://gcc.gnu.org/viewcvs?rev=270365&root=gcc&view=rev Log: Backport r268060 2019-04-15 Martin Liska Backport from mainline 2019-01-18 Martin Liska Richard Biener PR middle-end/88587 * cgraph.h (create_version_clone_with_body): Add new argument with attributes. * cgraphclones.c (cgraph_node::create_version_clone): Add DECL_ATTRIBUTES to a newly created decl. And call valid_attribute_p so that proper cl_target_optimization_node is set for the newly created declaration. * multiple_target.c (create_target_clone): Set DECL_ATTRIBUTES for declaration. (expand_target_clones): Do not call valid_attribute_p, it must be already done. * tree-inline.c (copy_decl_for_dup_finish): Reset mode for vector types. 2019-04-15 Martin Liska Backport from mainline 2019-01-18 Martin Liska PR middle-end/88587 * g++.target/i386/pr88587.C: New test. * gcc.target/i386/mvc13.c: New test. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/cgraph.h branches/gcc-8-branch/gcc/cgraphclones.c branches/gcc-8-branch/gcc/multiple_target.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-inline.c
[Bug middle-end/88587] ICE in expand_debug_locations, at cfgexpand.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Martin Liška --- Backported to GCC-8 branch, closing now.
[Bug sanitizer/90090] [7/8/9 Regression] ICE in mark_reachable_handlers, at tree-eh.c:3938 since r219202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90090 --- Comment #2 from Jakub Jelinek --- Created attachment 46165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46165&action=edit gcc9-pr90090.patch Untested fix.
[Bug sanitizer/90090] [7/8/9 Regression] ICE in mark_reachable_handlers, at tree-eh.c:3938 since r219202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90090 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/90088] 3 ops LEA should be avoided on Intel CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088 Richard Biener changed: What|Removed |Added Target|Intel x86 |x86_64-*-* i?86-*-* CC||hjl at gcc dot gnu.org --- Comment #3 from Richard Biener --- We have two related tunables, X86_TUNE_OPT_AGU and X86_TUNE_AVOID_LEA_FOR_ADDR. Probably related is that most uarchs have extra cost for complex addressing modes for moves (extra uop to generate the addres). But I wasn't aware that there's extra costs for the AGU op itself.
[Bug c++/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org Version|tree-ssa|8.3.1
[Bug c++/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078 Martin Liška changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #2 from Martin Liška --- I'm adding the pass maintainer to CC. @Walter: Do you have an account so that you'll be able to propose the patch to GCC patches mailing list?
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.5
[Bug tree-optimization/90071] [7/8/9 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071 --- Comment #3 from Richard Biener --- Matching expression match.pd:1195, generic-match.c:115 Applying pattern match.pd:1251, generic-match.c:17730 Matching expression match.pd:100, generic-match.c:22 Optimizing range tests e_21(ab) +[, 0] and +[-1, ] into (unsigned int) e_21(ab) + 1 <= 1 Index: gcc/tree-ssa-reassoc.c === --- gcc/tree-ssa-reassoc.c (revision 270358) +++ gcc/tree-ssa-reassoc.c (working copy) @@ -2143,7 +2143,8 @@ init_range_entry (struct range_entry *r, exp_type = boolean_type_node; } - if (TREE_CODE (arg0) != SSA_NAME) + if (TREE_CODE (arg0) != SSA_NAME + || SSA_NAME_OCCURS_IN_ABNORMAL_PHI (arg0)) break; loc = gimple_location (stmt); switch (code)
[Bug gcov-profile/90092] [GCOV] Wrong frequencies then the default label in switch statement is followed with no statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90092 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 85179 ***
[Bug gcov-profile/85179] [GCOV] A label followed with a blank statement is wrongly marked as not executed in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85179 --- Comment #2 from Martin Liška --- *** Bug 90092 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/90083] internal compiler error: in expand_debug_locations, at cfgexpand.c:5403 with -O3 and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90083 --- Comment #2 from Martin Liška --- Just for the record, this PR appeared on trunk in r247830, before that it was probably latent.
[Bug tree-optimization/90071] [7/8/9 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED CC||rguenth at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- reassoc does this: @@ -51,9 +75,11 @@ f: _7 = d_20(D) != 0; _9 = _4 < 0; - _10 = _7 | _9; + _18 = (unsigned int) e_21(ab); + _16 = _18 + 1; + _14 = _16 > 1; _17 = _4 > 1; - _6 = _10 | _17; + _6 = _14 | _7; _8 = (int) _6; _12 = (long int) _8; _13 = (void *) _12; it's likely folding _4 = e.1_3 + 1; _9 = _4 < 0; here. I'll take a look.
[Bug tree-optimization/90020] [7/8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020 --- Comment #19 from Dominique d'Humieres --- > Can you commit that change then? It's pre-approved since it only > affects -darwin and you tested that. Thx. Done at r270360. Note that I cannot test the additional option for darwin[89].
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-15 CC||ktkachov at gcc dot gnu.org Known to work||9.0 Summary|[AArch64] ICE during RTL|[7/8 Regression] [AArch64] |pass when member of union |ICE during RTL pass when |passed to copysignf |member of union passed to ||copysignf Ever confirmed|0 |1 Known to fail||6.5.0, 7.4.1, 8.3.1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed on GCC 8 branch as well as 7 and 6 (though 6 is not longer maintained). Trunk doesn't ICE though I don't know if it has been fixed or just made latent
[Bug tree-optimization/90020] [7/8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020 --- Comment #18 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Apr 15 07:56:43 2019 New Revision: 270360 URL: https://gcc.gnu.org/viewcvs?rev=270360&root=gcc&view=rev Log: 2019-04-15 Dominique d'Humieres PR tree-optimization/90020 * gcc.dg/torture/pr90020.c: Add linker options for darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr90020.c
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #3 from Richard Biener --- For -ffast-math doing this as a float FMA is probably fastest. I'm not sure whether doing temp1 * 5 as integer operation is any good given on archs like Zen you'll have a FP <-> INT domain crossing.
[Bug gcov-profile/90092] New: [GCOV] Wrong frequencies then the default label in switch statement is followed with no statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90092
Bug ID: 90092
Summary: [GCOV] Wrong frequencies then the default label in
switch statement is followed with no statement
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --enable-languages=c,c++
--disable-multilib --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 9.0.1 20190414 (experimental) (GCC)
$ cat small.c
int bar (int a)
{
int ret = 0;
switch (a)
{
case 1: ret = ret + 1; break;
default:
;// ret = ret + 2;
}
return ret;
}
int main ()
{
bar(1);
return 0;
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 9
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:int bar (int a)
-:2:{
1:3: int ret = 0;
1:4: switch (a)
-:5: {
1:6:case 1: ret = ret + 1; break;
1:7:default:
-:8: ;// ret = ret + 2;
-:9: }
-: 10:
1: 11: return ret;
-: 12:}
-: 13:
1: 14:int main ()
-: 15:{
1: 16: bar(1);
1: 17: return 0;
-: 18:}
Line #7 is wrongly marked as executed. It should be not executed.
I am not quite sure this should be reported as a new bug report. As there has
similar bug report 85179 while a label statement is followed with no
statements.
When the "default:" statement is not empty, the result is correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:80.00% of 10
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:int bar (int a)
-:2:{
1:3: int ret = 0;
1:4: switch (a)
-:5: {
1:6:case 1: ret = ret + 1; break;
#:7:default:
#:8: ret = ret + 2;
-:9: }
-: 10:
1: 11: return ret;
-: 12:}
-: 13:
1: 14:int main ()
-: 15:{
1: 16: bar(1);
1: 17: return 0;
-: 18:}
[Bug tree-optimization/90020] [7/8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020
--- Comment #17 from rguenther at suse dot de ---
On Mon, 15 Apr 2019, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020
>
> --- Comment #16 from Dominique d'Humieres ---
> > /* { dg-require-weak "" } */
> >
> > was supposed to make it UNSUPPORTED on targets where it doesn't work.
>
> Apparently this not enough. From gcc.dg/attr-weakref-1.c I see
>
> // { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target
> *-*-darwin*
> } }
> // { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } }
>
> The test links on x86_64-apple-darwin18 if I add
> -Wl,-undefined,dynamic_lookup.
Can you commit that change then? It's pre-approved since it only
affects -darwin and you tested that. Thx.
[Bug sanitizer/90090] [7/8/9 Regression] ICE in mark_reachable_handlers, at tree-eh.c:3938 since r219202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90090
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
--- gcc/tree-ssa-math-opts.c.jj 2019-04-08 10:11:28.620219138 +0200
+++ gcc/tree-ssa-math-opts.c2019-04-15 09:42:22.173868303 +0200
@@ -334,7 +334,8 @@ is_division_by (gimple *use_stmt, tree d
/* Do not recognize x / x as valid division, as we are getting
confused later by replacing all immediate uses x in such
a stmt. */
-&& gimple_assign_rhs1 (use_stmt) != def;
+&& gimple_assign_rhs1 (use_stmt) != def
+&& !stmt_can_throw_internal (cfun, use_stmt);
}
/* Return TRUE if USE_STMT is a multiplication of DEF by A. */
@@ -367,13 +368,12 @@ is_division_by_square (gimple *use_stmt,
{
if (gimple_code (use_stmt) == GIMPLE_ASSIGN
&& gimple_assign_rhs_code (use_stmt) == RDIV_EXPR
- && gimple_assign_rhs1 (use_stmt) != gimple_assign_rhs2 (use_stmt))
+ && gimple_assign_rhs1 (use_stmt) != gimple_assign_rhs2 (use_stmt)
+ && !stmt_can_throw_internal (cfun, use_stmt))
{
tree denominator = gimple_assign_rhs2 (use_stmt);
if (TREE_CODE (denominator) == SSA_NAME)
- {
- return is_square_of (SSA_NAME_DEF_STMT (denominator), def);
- }
+ return is_square_of (SSA_NAME_DEF_STMT (denominator), def);
}
return 0;
}
fixes this.
[Bug gcov-profile/90091] [GCOV] code formatting lead to incorrect code coverage for "if ( expr1 || expr2) " statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90091
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-15
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Martin Liška ---
Confirmed, it's a real limitation where '||' is on a different line than
f2(a)!=0x00ABCDEFL.
following works:
1:1:long f1(long a){return a&0xff00L;}
1:2:long f2(long a){return a&~0xff00L;}
-:3:
1:4:void main ()
-:5:{
1:6: long a = 0x89ABCDEF;
-:7:
1:8: if (f1(a)!=0x8900L
1:9: || f2(a)!=0x00ABCDEFL)
#: 10:abort();
1: 11: exit(0);
-: 12:}
[Bug tree-optimization/90020] [7/8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020
--- Comment #16 from Dominique d'Humieres ---
> /* { dg-require-weak "" } */
>
> was supposed to make it UNSUPPORTED on targets where it doesn't work.
Apparently this not enough. From gcc.dg/attr-weakref-1.c I see
// { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin*
} }
// { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } }
The test links on x86_64-apple-darwin18 if I add -Wl,-undefined,dynamic_lookup.
[Bug tree-optimization/90020] [7/8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020
--- Comment #15 from rguenther at suse dot de ---
On Sat, 13 Apr 2019, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020
>
> --- Comment #14 from Dominique d'Humieres ---
> The test gcc.dg/torture/pr90020.c fails on darwin:
>
> Undefined symbols for architecture x86_64:
> "_x", referenced from:
> _main in ccemobuO.o
> ld: symbol(s) not found for architecture x86_64
> collect2: error: ld returned 1 exit status
/* { dg-require-weak "" } */
was supposed to make it UNSUPPORTED on targets where it doesn't work.
[Bug gcov-profile/90091] New: [GCOV] code formatting lead to incorrect code coverage for "if ( expr1 || expr2) " statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90091
Bug ID: 90091
Summary: [GCOV] code formatting lead to incorrect code coverage
for "if ( expr1 || expr2) " statement
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --enable-languages=c,c++
--disable-multilib --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 9.0.1 20190414 (experimental) (GCC)
$ cat small.c
long f1(long a){return a&0xff00L;}
long f2(long a){return a&~0xff00L;}
void main ()
{
long a = 0x89ABCDEF;
if (f1(a)!=0x8900L||
f2(a)!=0x00ABCDEFL)
abort();
exit(0);
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:87.50% of 8
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:long f1(long a){return a&0xff00L;}
1:2:long f2(long a){return a&~0xff00L;}
-:3:
1:4:void main ()
-:5:{
1:6: long a = 0x89ABCDEF;
-:7:
2:8: if (f1(a)!=0x8900L||
1:9: f2(a)!=0x00ABCDEFL)
#: 10:abort();
1: 11: exit(0);
-: 12:}
Line #8 is wrongly marked as executed twice.
When Line #8 and Line #9 is in the same code line, the code coverage report is
correct as follows:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
libgcov profiling error:/home/yyb/cv-emi/small.gcda:overwriting an existing
profile data with a different timestamp
File 'small.c'
Lines executed:85.71% of 7
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:long f1(long a){return a&0xff00L;}
1:2:long f2(long a){return a&~0xff00L;}
-:3:
1:4:void main ()
-:5:{
1:6: long a = 0x89ABCDEF;
-:7:
1:8: if (f1(a)!=0x8900L||f2(a)!=0x00ABCDEFL)
#:9:abort();
1: 10: exit(0);
-: 11:}
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #5 from Martin Liška --- Can you please attach also original (unreduced pre-processed test-case), ideally created with GCC8?
