[Bug gcov-profile/90104] [GCOV] Wrong coverage for calling a function with variable arguments when they are embedded in a inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90104
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-16
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Confirmed, simplified test-case:
#include
long x = 0;
inline void __attribute__((always_inline))
bar (va_list ap)
{
x = va_arg (ap, double);
}
void foo (int i, ...)
{
va_list ap;
va_start (ap, i);
bar (ap);
va_end (ap);
}
int main ()
{
foo (18.0);
return 0;
}
At coverage pass, we have following GIMPLE:
$2 = void
(gdb) p debug_function(cfun->decl, 0)
foo (int i)
{
struct * ap;
struct ap[1];
double _6;
long int _7;
:
__builtin_va_start (&ap, 0);
ap_5 = ≈
_6 = .VA_ARG (ap_5, 0B, 0B);
:
_7 = (long int) _6;
x = _7;
:
__builtin_va_end (&ap);
ap ={v} {CLOBBER};
return;
}
$ gcov-dump -l pr90104.gcno
...
pr90104.gcno: 0100: 14:FUNCTION ident=1636255671,
lineno_checksum=0xf71f0366, cfg_checksum=0x7cb34af9, `foo' pr90104.c:11:6-17:1
pr90104.gcno:0141: 1:BLOCKS 5 blocks
pr90104.gcno:0143: 3:ARCS 1 arcs
pr90104.gcno: block 0: 2:0004(fall)
pr90104.gcno:0143: 5:ARCS 2 arcs
pr90104.gcno: block 2: 3:0004(fall) 1:0003(tree,fake)
pr90104.gcno:0143: 3:ARCS 1 arcs
pr90104.gcno: block 3: 4:0005(tree,fall)
pr90104.gcno:0143: 3:ARCS 1 arcs
pr90104.gcno: block 4: 1:0001(tree)
pr90104.gcno:0145: 11:LINES
pr90104.gcno: block 2:`pr90104.c':11, 14, 8
pr90104.gcno:0145: 10:LINES
pr90104.gcno: block 3:`pr90104.c':8, 9
pr90104.gcno:0145: 10:LINES
pr90104.gcno: block 4:`pr90104.c':16, 17
Line 8 is present in bb_2 and bb_3, thus it's incremented twice. It's an
artifact of early inlining.
[Bug c++/90108] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-16 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug middle-end/90095] [9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Blocks||85414 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85414 [Bug 85414] [8 Regression] ICE: in ix86_expand_prologue, at config/i386/i386.c:13810 with -Og -fgcse
[Bug rtl-optimization/90094] better handling of x == LONG_MIN on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-16 Component|target |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I guess this also applies to conditional branches. It might require to copy a to a scratch register in case it's value is live over the comparison (but then it saves a reg for the constant).
[Bug middle-end/90095] [8/9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Target Milestone|9.0 |8.4 Summary|[9 Regression] wrong code |[8/9 Regression] wrong code |with -Os -fno-tree-bit-ccp |with -Os -fno-tree-bit-ccp --- Comment #3 from Richard Biener --- rev is on the branch.
[Bug middle-end/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 Priority|P2 |P1 Summary|[8/9 Regression] wrong code |[9 Regression] wrong code |with -Os -fno-tree-bit-ccp |with -Os -fno-tree-bit-ccp --- Comment #4 from Jakub Jelinek --- (In reply to Richard Biener from comment #3) > rev is on the branch. No (but I made similar mistake). The PR had two revisions, only the second one, applied to trunk only (19 revisions after branching) and that is the one that broke this.
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #2 from Vittorio Zecca --- Still in trunk 270309. Optimization at least -O1 needed to reproduce the bug. /home/vitti/local/gcc-270309-undefined/bin/gcc -S gccerr70.c -O1 ../../gcc/gcc/poly-int.h:845:5: runtime error: signed integer overflow: 9223372036854775804 + 4 cannot be represented in type 'long int'
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- 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. That should be fine. I doubt very much that much (if any) user code uses those types directly.
[Bug tree-optimization/87042] UBSAN: poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87042 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #4 from Vittorio Zecca --- Still in trunk 270309. Requires optimization to reproduce. /home/vitti/local/gcc-270309-undefined/bin/gcc -S gccerr72.c [vitti cc]$/home/vitti/local/gcc-270309-undefined/bin/gcc -S gccerr72.c -O ../../gcc/gcc/poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'
[Bug tree-optimization/56049] [7/8/9 Regression] Simplification to constants not done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 --- Comment #24 from Richard Biener --- Author: rguenth Date: Tue Apr 16 07:55:41 2019 New Revision: 270378 URL: https://gcc.gnu.org/viewcvs?rev=270378&root=gcc&view=rev Log: 2019-04-16 Richard Biener PR tree-optimization/56049 * tree-ssa-loop-im.c (mem_ref_hasher::equal): Elide alias-set equality check if alias-set zero will prevail. * gfortran.dg/pr56049.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr56049.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- 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. > > That should be fine. I doubt very much that much (if any) user code > uses those types directly. Btw., I've bootstrapped both sparc-sun-solaris2.11 and i386-pc-solaris2.11 (Solaris 11.5 both) last night with trunk and there were no regressions. Thanks a lot.
[Bug tree-optimization/56049] [7/8 Regression] Simplification to constants not done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Summary|[7/8/9 Regression] |[7/8 Regression] |Simplification to constants |Simplification to constants |not done|not done Known to fail||7.4.0, 8.3.0 --- Comment #25 from Richard Biener --- Fixed.
[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 #6 from bin cheng ---
(In reply to Martin Liška from comment #5)
> (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?
Implementing the capping in comp_cost::operators to infinite_cost is less
invasive. OTOH, capping bb_freq/loop_freq has its own advantages, because:
Once cost reaches to infinite, it becomes meaningless in comparison as well as
candidate choosing; capping bb_freq/loop_freq can still express hotness of
code to some extend.
Let's fix the issue by capping comp_cost::operators first for this stage 4 and
revisit the idea capping bb_freq/loop_freq with more benchmark data in next
Stage 1. How about that?
Thanks.
>
> >
> >
> > 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 c++/90108] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- So we have a non-GCed INTEGER_TYPE that has a GCed TYPE_NAME. IIRC changes there recently, PR89933. We free that TYPE_NAME here (as expected...): #1 0x009584ee in duplicate_decls ( newdecl=, olddecl=, newdecl_is_friend=false) at /space/rguenther/src/svn/trunk2/gcc/cp/decl.c:2793 2793 ggc_free (newdecl); Jakub - you fiddled here, can you look at this one, too?
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #69 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #68) > Created attachment 46176 [details] > revised fixincludes patch. > > 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. I will test this fix tonight when I have access to enough electricity again. It looks like this really affects things, as my try to compile LLVM failed: $ make [ 0%] Built target LLVMDemangle [ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o In file included from /usr/include/sys/sysctl.h:83, from /Users/reuter/local/packages/llvm-project/llvm/lib/Support/Host.cpp:1224: /usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type 94 | _Atomic u_long cr_ref; /* reference count */ | ^~~ make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o] Error 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
--- Comment #7 from Martin Liška ---
(In reply to bin cheng from comment #6)
> (In reply to Martin Liška from comment #5)
> > (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?
> Implementing the capping in comp_cost::operators to infinite_cost is less
> invasive. OTOH, capping bb_freq/loop_freq has its own advantages, because:
> Once cost reaches to infinite, it becomes meaningless in comparison as well
> as candidate choosing; capping bb_freq/loop_freq can still express hotness
> of code to some extend.
> Let's fix the issue by capping comp_cost::operators first for this stage 4
> and revisit the idea capping bb_freq/loop_freq with more benchmark data in
> next Stage 1. How about that?
>
> Thanks.
Sounds good. Can you please work on that Bin?
[Bug tree-optimization/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 #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 16 08:24:47 2019 New Revision: 270379 URL: https://gcc.gnu.org/viewcvs?rev=270379&root=gcc&view=rev Log: PR tree-optimization/90090 * tree-ssa-math-opts.c (is_division_by): Ignore divisions that can throw internally. (is_division_by_square): Likewise. Formatting fix. * g++.dg/opt/pr90090.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr90090.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[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 #4 from Jakub Jelinek --- Author: jakub Date: Tue Apr 16 08:26:26 2019 New Revision: 270380 URL: https://gcc.gnu.org/viewcvs?rev=270380&root=gcc&view=rev Log: PR rtl-optimization/90082 * dce.c (can_delete_call): New function. (deletable_insn_p, mark_insn): Use it. * gcc.dg/pr90082.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr90082.c Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #70 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #69) > (In reply to Iain Sandoe from comment #68) > > Created attachment 46176 [details] > > revised fixincludes patch. > > > > 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. > > I will test this fix tonight when I have access to enough electricity again. > > It looks like this really affects things, I am not clear what you're reporting here - the patch will not "do anything" until you build GCC with it applied, and then install the built compiler. > as my try to compile LLVM failed: Does this mean, "when building LLVM on OSX 10.14.2 using GCC as the bootstrap compiler"? (I'm not sure what's wrong here - if the compiler bootstrap succeeds, then the compiler should be able to process the headers - if the code is C11, then _Atomic should be accepted, if it's C++ then _Atomic should be mapped to volatile).
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #71 from Iain Sandoe --- (In reply to Iain Sandoe from comment #70) > (In reply to Jürgen Reuter from comment #69) > > (In reply to Iain Sandoe from comment #68) > Does this mean, "when building LLVM on OSX 10.14.2 using GCC as the > bootstrap compiler"? > > (I'm not sure what's wrong here - if the compiler bootstrap succeeds, then > the compiler should be able to process the headers - if the code is C11, > then _Atomic should be accepted, if it's C++ then _Atomic should be mapped > to volatile). I guess that means for some other piece of (C++) code there's some use of _Atomic that's being messed up by including or some other header that includes ucred.h. ... will try to repeat ...
[Bug target/90096] Misleading option hint for AVX intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90096 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Apr 16 08:40:58 2019 New Revision: 270381 URL: https://gcc.gnu.org/viewcvs?rev=270381&root=gcc&view=rev Log: PR target/90096 * config/i386/i386.c (ix86_target_string): Add ADD_ABI_P argument, only print -m64/-mx32/-m32 if it is true. (ix86_debug_options, ix86_function_specific_print): Pass true as ADD_ABI_P to ix86_target_string. (ix86_expand_builtin): Adjust ix86_target_string caller, pass true as ADD_ABI_P only if OPTION_MASK_ISA_64BIT is set in bisa and in that case or into it OPTION_MASK_ISA_ABI_64 or OPTION_MASK_ISA_ABI_X32. * gcc.target/i386/pr90096.c: New test. * gcc.target/i386/pr69255-1.c: Adjust expected diagnostics. * gcc.target/i386/pr69255-2.c: Likewise. * gcc.target/i386/pr69255-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr90096.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr69255-1.c trunk/gcc/testsuite/gcc.target/i386/pr69255-2.c trunk/gcc/testsuite/gcc.target/i386/pr69255-3.c
[Bug debug/90109] New: gstabs flag generates wrong entry for long on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109
Bug ID: 90109
Summary: gstabs flag generates wrong entry for long on x86_64
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: nebiun at hotmail dot com
Target Milestone: ---
Make a bug.c file with content:
typedef struct {
int a;
short unsigned int b;
char c[2];
long int d;
long long int e;
} mytype_t;
compile it with:
gcc -c -gstabs bug.c
obtain a bug.o object file (this is the output of command: file bug.o)
bug.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
use objdump to get debug infos from bug.o:
objdump --debugging bug.o
This is the output:
bug.o: file format elf64-x86-64
bug.c:
typedef int32 int;
typedef int8 char;
typedef uint32 long int;
typedef uint32 unsigned int;
typedef uint32 long unsigned int;
typedef uint32 __int128;
typedef uint32 __int128 unsigned;
typedef uint32 long long int;
typedef uint64 long long unsigned int;
typedef int16 short int;
typedef uint16 short unsigned int;
typedef int8 signed char;
typedef uint8 unsigned char;
typedef float float;
typedef double double;
typedef float128 long double;
typedef float _Decimal32;
typedef double _Decimal64;
typedef float128 _Decimal128;
typedef void void;
typedef struct %anon1 { /* size 24 */
int a; /* bitsize 32, bitpos 0 */
short unsigned int b; /* bitsize 16, bitpos 32 */
char c[2]:uint32; /* bitsize 16, bitpos 48 */
long int d; /* bitsize 64, bitpos 64 */
long long int e; /* bitsize 64, bitpos 128 */
} mytype_t;
'long int d' and 'long long int e' inside the struct have correct bitsize (64),
but typedef for 'long int', 'long unsigned int' and 'long long int' are defined
as uint32 and not uint64
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #72 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #71) > (In reply to Iain Sandoe from comment #70) > > (In reply to Jürgen Reuter from comment #69) > > > (In reply to Iain Sandoe from comment #68) > > > Does this mean, "when building LLVM on OSX 10.14.2 using GCC as the > > bootstrap compiler"? > > > > (I'm not sure what's wrong here - if the compiler bootstrap succeeds, then > > the compiler should be able to process the headers - if the code is C11, > > then _Atomic should be accepted, if it's C++ then _Atomic should be mapped > > to volatile). > > I guess that means for some other piece of (C++) code there's some use of > _Atomic that's being messed up by including or some other header > that includes ucred.h. > > ... will try to repeat ... This issue was with the fixincludes from comment #45, not yet with the new one. I have to compile/bootstrap with the new fix tonight.
[Bug tree-optimization/90090] [7/8 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 Known to work||9.0 Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |mark_reachable_handlers, at |mark_reachable_handlers, at |tree-eh.c:3938 since|tree-eh.c:3938 since |r219202 |r219202 Known to fail|9.0 | --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[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 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/90088] 3 ops LEA should be avoided on Intel CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088
--- Comment #4 from Hongtao.liu ---
(In reply to Richard Biener from comment #3)
> 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.
Yes, m_SANDYBRIDGE is not in X86_TUNE_OPT_AGU and X86_TUNE_AVOID_LEA_FOR_ADDR.
But when I try
gcc -O2 test.c -S -mtune=bonnell
It fails to avoid LEAL instruction, since m_BONNELL is in both tunables,
I believe there's other places need to be handled such as
/* Return true if usage of lea INSN has performance advantage
over a sequence of instructions. Instructions sequence has
SPLIT_COST cycles higher latency than lea latency. */
static bool
ix86_lea_outperforms (rtx_insn *insn, unsigned int regno0, unsigned int regno1,
unsigned int regno2, int split_cost, bool has_scale)
{
int dist_define, dist_use;
[Bug go/90110] New: [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 Bug ID: 90110 Summary: [9 Regression] libgo fails to build against glibc 2.19 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: rguenth at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- When building GCC 9 against glibc 2.19 I get [ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data for 'Float32frombits': expected integer at 79 [ 6667s]13 | import "math" [ 6667s] |^ [ 6667s] ../../../../libgo/go/math/unsafe.go:18: error: expected pointer [ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data for 'Float64frombits': expected integer at 79 [ 6667s]13 | import "math" [ 6667s] |^ [ 6667s] ../../../../libgo/go/math/unsafe.go:29: error: expected pointer [ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data for 'Float32bits': expected integer at 79 [ 6667s]13 | import "math" [ 6667s] |^ [ 6667s] ../../../../libgo/go/math/unsafe.go:12: error: expected pointer [ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data for 'Float64bits': expected integer at 79 [ 6667s]13 | import "math" [ 6667s] |^ [ 6667s] ../../../../libgo/go/math/unsafe.go:23: error: expected pointer [ 6667s] Makefile:2838: recipe for target 'strconv.lo' failed [ 6667s] make[8]: *** [strconv.lo] Error 1 GCC 8 is fine.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 Richard Biener changed: What|Removed |Added Keywords||build Target||x86_64-*-*, i?86-*-*, ||ppc64le-*-*, aarch64-*-*, ||s390x-*-* Priority|P3 |P4 Target Milestone|--- |9.0
[Bug target/90103] ICE building Glibc's e_atan2f.c with -O2 -mcpu=hs38_linux -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90103 --- Comment #1 from Claudiu Zissulescu --- Probably,this patch needs to be backported: [ARC] Update fma expansions. Accept at most a single constant for fma patterns. gcc/ 2018-03-21 Claudiu Zissulescu * config/arc/fpu.md (fmasf4): Force operand to register. (fnmasf4): Likewise. gcc/testsuite 2018-03-21 Claudiu Zissulescu * gcc.target/arc/fma-1.c: New test. SVN: 261543
[Bug c++/65799] Allows constexpr conversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||msebor at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #5 from Jonathan Wakely ---
Martin, do you want to take a look at these cases, which your 2238909 change
didn't handle?
char gdummy = {};
constexpr int* test_global = (int*)(void*)&gdummy; // ill-formed
static_assert(test_global);
constexpr bool test_local() {
float dummy = {};
(int*)(void*)&dummy; // ill-formed
return true;
}
static_assert(test_local(), "");
[Bug c++/90085] c++17 template argument deduction results in missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90085 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-16 Ever confirmed|0 |1
[Bug c++/90107] rejects-valid on global-namespace-qualified variable declared after class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90107 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-16 Ever confirmed|0 |1
[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org Known to work||9.0 --- Comment #2 from Jonathan Wakely --- This was changed by Jason in r269692 so let's ask him. Don't require 'bool' in a concept definition. * parser.c (cp_parser_decl_specifier_seq): Support C++20 concept-definition syntax without 'bool'.
[Bug libstdc++/90050] std::filesystem::path segfault in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- The -lstdc++fs requirement for std::filesystem in GCC 8 is documented in several places: https://gcc.gnu.org/onlinedocs/gcc-8.3.0/libstdc++/manual/manual/using.html#manual.intro.using.flags https://gcc.gnu.org/onlinedocs/gcc-8.3.0/libstdc++/manual/manual/status.html#status.iso.2017 https://gcc.gnu.org/onlinedocs/gcc-8.3.0/libstdc++/manual/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.experimental I don't know why it crashes with Ubuntu, it should be a linker error. I suspect Ubuntu is doing something silly like providing libstdc++.so from GCC 9, which defines std::filesystem::path differently, and so is not compatible with C++17 code compiled using GCC 8.
[Bug debug/90109] gstabs flag generates wrong entry for long on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109 Richard Biener changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Richard Biener --- GCC 8 seems to get 'long int' correct: typedef int32 int; typedef int8 char; typedef int64 long int; typedef uint32 unsigned int; typedef uint32 long unsigned int; typedef uint32 __int128; typedef uint32 __int128 unsigned; typedef int64 long long int; typedef uint64 long long unsigned int; typedef int16 short int; typedef uint16 short unsigned int; typedef int8 signed char; typedef uint8 unsigned char; typedef float float; typedef double double; typedef float128 long double; long double is also wrong. GCC does if (print_int_cst_bounds_in_octal_p (type, low, high)) ... else /* Output other integer types as subranges of `int'. */ dbxout_range_type (type, low, high); probably that's the issue. It looks like you need to use -gstabs+ to allow representing those types at all (stabs with GNU extensions). With -gstabs+ I see /tmp/t.c: typedef int32 int; typedef int8 char; typedef int64 long int; typedef uint32 unsigned int; typedef uint64 long unsigned int; typedef void __int128; typedef void __int128 unsigned; typedef int64 long long int; typedef uint64 long long unsigned int; typedef int16 short int; typedef uint16 short unsigned int; typedef int8 signed char; typedef uint8 unsigned char; typedef float float; typedef double double; typedef float128 long double; (long double still wrong) So - INVALID? Jim, you are "remotely" listed as MAINTAINER for stabs.
[Bug libstdc++/90050] std::filesystem::path segfault in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050 --- Comment #5 from Jonathan Wakely --- Although if you link with -lstdc++fs then it should work OK, because the incompatible std::filesystem symbols in libstdc++.so.6.0.26 won't be used.
[Bug fortran/90111] New: Placement of Fortran OpenACC 'routine' directive inside 'specification-part'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90111 Bug ID: 90111 Summary: Placement of Fortran OpenACC 'routine' directive inside 'specification-part' Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc, rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- OpenACC 2.7 (same in 2.6), in section 2.15.1. "Routine Directive" states that "In Fortran, the 'routine' directive without a name may appear within the specification part of a subroutine or function definition, or within an interface body for a subroutine or function in an interface block, and applies to the containing subroutine or function. The 'routine' directive with a name may appear in the specification part of a subroutine, function or module, and applies to the named subroutine or function". It therefore seems wrong to me that the following gets rejected: subroutine s !$acc routine seq implicit none integer :: i i = 0 end subroutine s 2 | !$acc routine seq | 2 3 | implicit none | 1containi Error: IMPLICIT NONE statement at (1) cannot follow !$ACC ROUTINE statement at (2) Or am I misunderstanding something about 'implicit-stmt'? But at least for the 'routine' directive without a name, which always implicitly applies to the containing subprogram etc., this placement should not matter at all (thus, the above be valid). I have not looked for any other such rejects-valid constructs.
[Bug fortran/90112] New: internal procedure using module procedure instead of "sibling" internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90112 Bug ID: 90112 Summary: internal procedure using module procedure instead of "sibling" internal procedure Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jellby at yahoo dot com Target Milestone: --- In some cases an internal procedure will use a module procedure instead of another internal procedure (in the same host unit) with the same name. In the example below, R(x) calls f(x), but it uses the module's f(x) instead of the one internal to g(x) (as probably intended). module test_functions contains subroutine f(x) implicit none real, intent(inout) :: x x = 2 * x end subroutine f subroutine g(x) implicit none real, intent(inout) :: x call R(x) contains subroutine R(x) implicit none real, intent(inout) :: x call f(x) end subroutine R subroutine f(x) implicit none real, intent(inout) :: x x = 3 * x end subroutine f end subroutine g end module program scope use test_functions real :: x = 3.0, y = 3.0 call f(x) call g(y) write(*, *) x, y end program Compiling and running with gfortran 5.4, 7.4, 8.1, gives: 6. 6. Compiling and running with ifort 18.0 gives: 6.00 9.00 This does not happen if f(x) is a function instead of a subroutine, or if the call to f(x) is made directly in g(x) rather than in R(x).
[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Jambor --- Yes. (I have just double checked verified GCC 7 is not affected.)
[Bug target/90103] ICE building Glibc's e_atan2f.c with -O2 -mcpu=hs38_linux -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90103 --- Comment #2 from Alexey Brodkin --- Indeed, proposed back-port fixes that problem! May we get it back-ported to 8.3.0 branch?
[Bug c++/86243] unknown attribute before throw causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |9.0
--- Comment #5 from Jonathan Wakely ---
(In reply to Hannes Hauswedell from comment #0)
> This strongly looks like a bug. If one encloses the if-block in braces, I
> instead get a warning:
>
> int main()
> {
> if (1 == 2) [[unlikely]]
> {
> throw int{};
> }
>
> return 2;
> }
>
> results in:
>
> % g++7 -std=c++17 test.cpp
> test.cpp: In function 'int main()':
> test.cpp:3:17: warning: attributes at the beginning of statement are ignored
> [-Wattributes]
> if (1 == 2) [[unlikely]]
> ^
That warning is Bug 89962.
But this bug has been fixed by r266223 and the code is accepted now.
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #6 from rene.r...@fu-berlin.de ---
Here is the code snippet that triggers the ICE:
#include
#include
#include
int main()
{
std::vector v{0, 1, 2, 3, 4};
for (auto e : v | ranges::view::reverse)
{
std::cout << e << '\n';
}
return 0;
}
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #7 from rene.r...@fu-berlin.de --- Created attachment 46177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46177&action=edit preprocessed source file from gcc8 (no ICE) This is the compressed but unreduced preprocessed source file when compiling with gcc 8.3.0.
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #3 from David Binderman --- I'd be happy to help out with any testing of any speculative patch for this bug. I am surprised that more than 64 bits of precision are required. Would a data type like float or double do the job ? Less precision, more range.
[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90001 --- Comment #5 from Roman Zhuykov --- Retested patch separately, everything works. Have found 2 more slow Fortran examples on (obsolete) spu platform and with additional options like -O1/O2 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions gfortran.dg/sms-2.f90 gfortran.dg/forall_10.f90 Compilation| time, sec |unpatched vs patched| sms options forall_10 | 35.02 0.66 | -fmodulo-sched forall_10 | 87.44 0.52 | -fmodulo-sched -fmodulo-sched-allow-regmoves sms-2 | 34.58 0.44 | -fmodulo-sched sms-2 | 86.77 0.27 | -fmodulo-sched -fmodulo-sched-allow-regmoves
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Martin Liška changed: What|Removed |Added Keywords||needs-bisection, ||needs-reduction Status|WAITING |NEW Known to work||8.2.0, 8.3.0 Known to fail||8.1.0, 9.0 --- Comment #8 from Martin Liška --- Confirmed, thanks for test-case. I'm both reducing and bisecting that..
[Bug testsuite/90113] New: Useless torture mode for gfortran.dg tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90113 Bug ID: 90113 Summary: Useless torture mode for gfortran.dg tests Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at ispras dot ru Target Milestone: --- I’ve recently found that tests, which are placed in gcc/testsuite/gfortran.dg folder are running in “torture” mode with different optimization options. While working with PR90001 I’ve looked into sms-2.f90 and forall_10.f90 tests from gfortran.dg. I analyzed only compilation time in that PR, but also was wondered with that these tests were compiled several times with lines like: sms-2.f90: “-O0 -O2 -fmodulo-sched” “-O1 -O2 -fmodulo-sched” ... “-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -O2 -fmodulo-sched” forall_10.f90 “-O0 -O” “-O1 -O” ... “-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -O” I’ve found a discussion when gfortran.dg/dg.exp was added in 2004, and there Joseph mentioned “torture” ideas: https://gcc.gnu.org/ml/gcc-patches/2004-07/msg01131.html “gcc.c-torture: multiple optimization options, built with -w to disable all warnings. gcc.dg: no looping over multiple options, defaults to -ansi -pedantic if no options given. gcc.dg/torture: like gcc.dg (so no -w) but loops over multiple options. Much of gcc.dg that uses some optimization options belongs in there.” I’ve started working with gcc a bit later, but I always thought, that same logic can be applied to other languages. And now I know that in fortran tests it is broken since that old time. Looking into recent commits (which add new fortran tests) shows that people also wrongly suppose that difference between gfortran.fortran-torture and gfortran.dg is same as in C language test folders (gcc.c-torture and gcc.dg). So, a lot of tests in gfortran.dg contain optimization level option, and this leads to many useless torture runs. In most torture option lines only optimization level is set, and an option inside test overrides that level. Maybe this broken logic should be fixed and we have to disable torture runs in gfortran.dg and run them like gcc.dg tests?
[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-16 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It's definitely a library bug. The problem is shown by the diagnostic messages. A DEBUG::debug vector can be constructed from a NORMAL::vector, because it has an extra constructor. Your conversion operator allows your type to convert to either DEBUG::vector or NORMAL::vector. Both of those types can convert to DEBUG::vector, so there are two equally good conversion sequences, which is ambiguous.
[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003 --- Comment #4 from rene.r...@fu-berlin.de --- Hi gcc-team, is there any news about this issue? Let me know, if you need more information. Kind regards
[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > A DEBUG::debug vector s/DEBUG::debug vector/DEBUG::vector/
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Roman Zhuykov changed: What|Removed |Added CC||zhroma at ispras dot ru --- Comment #12 from Roman Zhuykov --- Not sure if I have to reopen it, but fix wasn’t correct. In this example we don’t have -fmodulo-sched-allow-regmoves enabled and we should not create any register moves at all. More discussion and proper fix: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00632.html
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #49 from Florian Weimer ---
(In reply to Bernd Edlinger from comment #48)
> (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 don't think the target pragma/attribute is supported in Ada.
pragma Machine_Attribute (Subprogram, "target", "general-regs-only");
appears to be ignored (even if I use a string which would be accepted by the
C/C++ pragma for that target, and not "general-regs-only". But it's been years
since I did much Ada programming.
[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102 --- Comment #3 from Jonathan Wakely --- I'm not sure if the original testcase is actually required to compile. Implementations are allowed to add additional constructors, and they could take an arbitrary type with a .clear() member. But as a QoI matter we do want the same code to compile with debug mode as for normal mode.
[Bug middle-end/90114] New: Predetermined private levels for variables declared in OpenACC accelerator routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114 Bug ID: 90114 Summary: Predetermined private levels for variables declared in OpenACC accelerator routines Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc, wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- OpenACC 2.7 (same in 2.6), in section 2.6.1. "Variables with Predetermined Data Attributes" mandates that "Variables declared in 'seq' routine are private to the thread that made the call. Variables declared in 'vector' routine are private to the worker that made the call and shared across the threads associated with the vector lanes of that worker. Variables declared in 'worker' or 'gang' routine are private to the gang that made the call and shared across the threads associated with the workers and vector lanes of that gang".
[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #4 from Frederico Lamberti Pissarra --- My suggestion is to do a simple jmp after .L8 label and test the condition before sqrtss (or fsqrt, or sqrtsd...): f: pxor %xmm2,%xmm2 ucomiss %xmm0,%xmm2 ja .L8 sqrtss %xmm0,%xmm0 ret .L8: jmp sqrtf@PLT
[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 --- Comment #5 from Frederico Lamberti Pissarra --- CLANG 6 creates a similar code: f: xorps %xmm1,%xmm1 ucomiss %xmm1,%xmm0 jb .L8 # more intutive test... sqrtss ret .L8: jmp sqrtf@PLT
[Bug middle-end/90115] New: OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 Bug ID: 90115 Summary: OpenACC: predetermined private levels for variables declared in blocks Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc, wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- OpenACC 2.7 (same in 2.6), in section 2.6.1. "Variables with Predetermined Data Attributes" mandates that "Variables declared in a C block that is executed in 'vector-partitioned' mode are private to the thread associated with each vector lane. Variables declared in a C block that is executed in 'worker-partitioned' 'vector-single' mode are private to the worker and shared across the threads associated with the vector lanes of that worker. Variables declared in a C block that is executed in 'worker-single' mode are private to the gang and shared across the threads associated with the workers and vector lanes of that gang".
[Bug rtl-optimization/86438] [8 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438 --- Comment #12 from Alexandre Oliva --- Author: aoliva Date: Tue Apr 16 12:44:46 2019 New Revision: 270388 URL: https://gcc.gnu.org/viewcvs?rev=270388&root=gcc&view=rev Log: [PR86438] avoid too-long shift in test The test fell back to long long and long when __int128 is not available, but it assumed sizeof(long) < sizeof(long long) because of a shift count that would be out of range for a long long if their widths are the same. Fixed by splitting it up into two shifts. for gcc/testsuite/ChangeLog PR rtl-optimization/86438 * gcc.dg/torture/pr86438.c: Split up too-wide shift. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr86438.c
[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528 --- Comment #5 from Alexandre Oliva --- Author: aoliva Date: Tue Apr 16 12:44:57 2019 New Revision: 270389 URL: https://gcc.gnu.org/viewcvs?rev=270389&root=gcc&view=rev Log: [PR89528] reset debug uses of return value when dropping dead RTL call When we remove an RTL call, we wouldn't clean up references to the return value of the call in debug insns. Make it so that we do. for gcc/ChangeLog PR debug/89528 * valtrack.c (dead_debug_insert_temp): Reset debug references to the return value of a call being removed. for gcc/testsuite/ChangeLog PR debug/89528 * gcc.dg/guality/pr89528.c: New. Added: trunk/gcc/testsuite/gcc.dg/guality/pr89528.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/valtrack.c
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #1 from Ian Lance Taylor --- The pathnames suggest that this is the -m32 build. Can you attach the file TARGET/32/libgo/math.gox?
[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alexandre Oliva --- Fixed
[Bug debug/90017] gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90017 --- Comment #5 from Alexandre Oliva --- I think it's more of a missing feature than a bug. I believe GDB folks already know about this, though maybe not about this specific manifestation thereof.
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Bug 82738 depends on bug 89528, which changed state. Bug 89528 Summary: Wrong debug info generated at -Og [gcc-trunk] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug other/88790] No warning for misleading indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790 Segher Boessenkool changed: What|Removed |Added CC||daniel.marjamaki at gmail dot com --- Comment #3 from Segher Boessenkool --- Let's try that...
[Bug other/88790] No warning for misleading indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790 --- Comment #4 from Segher Boessenkool --- (Yup, worked).
[Bug libstdc++/90050] std::filesystem::path segfault in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050 --- Comment #6 from Mihai Preda --- OK, thanks. So if on Ubuntu 19.04, the default compiler produces without errors/warnings, from valid source code, an executable that crashes, that's programmer error?! I understand the explanation, but there is a problem. Maybe the bug is not with gcc but with Ubuntu, but a bug there is.
[Bug debug/89983] Missing debug info for final loop IV value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89983 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Alexandre Oliva --- It appears to me that a debugger with support for location views will address the problems you reported; I'm not so sure about the first issue (inside the loop), but certainly the second one (at the asm).
[Bug c/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 Alexander Monakov changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2019-04-16 CC||amonakov at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #6 from Alexander Monakov --- Reopening and confirming, GCC's code looks less efficient than possible for no good reason. CDCE does y = sqrt (x); ==> y = IFN_SQRT (x); if (__builtin_isless (x, 0)) sqrt (x); but it could do y = IFN_SQRT (x); if (__builtin_isless (x, 0)) y = sqrt (x); (note two assignments to y) or to mimic LLVM's approach: if (__builtin_isless (x, 0)) y = sqrt (x); else y = IFN_SQRT (x);
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #73 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #68) > Created attachment 46176 [details] > revised fixincludes patch. > > 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. This fix works for me on Darwin 10.14.4, XCode 10.2, with r270377.
[Bug libstdc++/90050] std::filesystem::path segfault in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050 --- Comment #7 from Jonathan Wakely --- See https://bugs.launchpad.net/ubuntu/+source/gcc-8/+bug/1824721 where I said: "for now the short answer is "C++17 support in GCC 8 is experimental, the onus is on you to link correctly"
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #74 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #73) > (In reply to Iain Sandoe from comment #68) > > Created attachment 46176 [details] > > revised fixincludes patch. > > > > > 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. > > This fix works for me on Darwin 10.14.4, XCode 10.2, with r270377. Thanks, does that include a test suite run and/or building something substantial (e.g. LLVM)? .. sorry to pass this on, but right now as noted, very limited access to Darwin test resources.
[Bug c++/86953] [7/8 Regression] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86953 --- Comment #8 from Rémi Ducceschi --- It seems to be fixed on the last version available on wandbox.org (gcc HEAD 9.0.1 201904): https://wandbox.org/permlink/Tu4T8jEXDDtDw0OS Though it doesn't work on any other versions (8.3.0...). Any chance to see the fix in the 8 branch? Anyway, thanks a lot :)
[Bug target/90088] 3 ops LEA should be avoided on Intel CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088 --- Comment #5 from H.J. Lu --- We should first add an LEA microbenchmark to https://gitlab.com/x86-benchmarks/microbenchmark
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Martin Liška changed: What|Removed |Added Attachment #46092|0 |1 is obsolete|| --- Comment #9 from Martin Liška --- Created attachment 46178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46178&action=edit Reduced test-case
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Martin Liška changed: What|Removed |Added Keywords|needs-bisection,|ice-on-valid-code |needs-reduction | CC||jason at gcc dot gnu.org --- Comment #10 from Martin Liška --- Started with r269746.
[Bug c++/65799] Allows constexpr conversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799 Martin Sebor changed: What|Removed |Added Blocks||55004 --- Comment #6 from Martin Sebor --- Sure, I can look into it sometime in stage 1. But I'm not sure these bugs are related. The test case in comment #0 and those in pr60760 and pr71091 are about invalid uses of null pointers in constexpr contexts. The test cases here don't involve bull pointers. Rejecting invalid casts was the subject of pr49171 (fixed in r259629). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003 Marek Polacek changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #5 from Marek Polacek --- This is actually a duplicate of 89953. *** This bug has been marked as a duplicate of bug 89953 ***
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #11 from Marek Polacek --- *** Bug 90003 has been marked as a duplicate of this bug. ***
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek --- Another test: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003#c3
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 65799, which changed state. Bug 65799 Summary: Allows constexpr conversion from cv void * to other type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug c++/65799] Allows constexpr conversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Eric, could you open a new PR and CC Martin please?
[Bug c++/90080] [8 Regression] SFINAE failure with static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90080 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-16 Known to work||4.7.1, 7.4.0, 9.0 Summary|SFINAE failure with |[8 Regression] SFINAE |static_cast |failure with static_cast Ever confirmed|0 |1 Known to fail||8.1.0, 8.2.0, 8.3.0 --- Comment #1 from Jonathan Wakely --- (In reply to Alex from comment #0) > This looks like a regression as a similar error is described here > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44267 Agreed. It works with GCC 7 and with trunk, but not GCC 8.
[Bug c++/87748] [8 Regression] G++-8 treats SFINAE as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748 Jonathan Wakely changed: What|Removed |Added CC||alex at grundis dot de --- Comment #5 from Jonathan Wakely --- *** Bug 90080 has been marked as a duplicate of this bug. ***
[Bug c++/90080] [8 Regression] SFINAE failure with static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90080
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Jonathan Wakely ---
Reduced:
struct false_type { static constexpr bool value = false; };
struct true_type { static constexpr bool value = true; };
template struct enable_if { };
template struct enable_if { using type = T; };
template T&& declval();
template
struct is_static_castable : false_type
{};
template
struct is_static_castable(declval()))> :
true_type
{};
template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return static_cast(from);
}
template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return dynamic_cast(from);
}
struct BarBase{ virtual ~BarBase() = default;};
struct Bar : virtual BarBase{};
Bar* foo(BarBase* b){
return safePtrCast(b);
}
This started to fail with r258824:
PR c++/78489 - wrong SFINAE behavior.
PR c++/84489
* pt.c (type_unification_real): Don't defer substitution failure.
And was fixed on trunk by r269921:
PR c++/87748 - substitution failure error with decltype.
This issue is similar to PR 87480; in both cases we were doing
non-dependent
substitution with processing_template_decl set, leading to member access
expressions seeming still instantiation-dependent, and therefore decltype
not being simplified to its actual type. And as in that PR, the fix is to
clear processing_template_decl while substituting a default template
argument.
* pt.c (most_specialized_partial_spec): Clear
processing_template_decl.
So this looks like a dup of that PR, which is still present on gcc-8-branch.
*** This bug has been marked as a duplicate of bug 87748 ***
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #13 from Marek Polacek ---
Adjusted testcase that is compiled with GCC 8.3 without errors:
namespace a {
template struct d { static constexpr int f = c; };
template struct g;
template h i(int);
template auto ab() -> decltype(i(0));
} // namespace a
namespace aa {
template using ae = a::d;
struct af {
template using ag = ac;
};
template using ah = af;
template using aj = typename ah::template ag;
} // namespace aa
namespace a {
template class ak {
public:
ak(b);
};
} // namespace a
namespace al {
template struct am;
template using an = am;
template struct v { template using ap = ao; };
template
using aq = typename v::template ap;
struct as {
template void at();
};
bool e();
namespace ar {
template concept bool au = requires { as::at; };
template concept bool j = requires { e(); };
template struct k;
template struct k : aa::ae> {};
template struct l : k> {};
template struct m { using aw = aq::f, const
int, av>; };
template using n = m>;
} // namespace ar
template struct am : ar::n {
using ax = ar::n;
using typename ax::aw;
auto operator*() -> aw;
auto operator++() -> am;
};
template auto operator!=(av, ay) -> bool;
template concept bool az = a::g::f;
struct {
template struct o {};
template using bb = o>;
template auto operator()(ba) noexcept(noexcept(bb{})) {}
} end;
template using p = decltype(a::ab);
template concept bool w = requires(ac q) { end(q); };
template concept bool r = w;
template concept bool bc = r;
struct x {
template
friend auto operator|(bd, be) -> decltype(be ::bf(a::ab, a::ab()));
};
namespace bg {
template struct y : x {
bh s;
template static auto bf(u z, bi bj) {
return bj.s(z);
}
};
} // namespace bg
struct bk {
template auto begin() -> an>>;
int end();
};
namespace bg {
struct bm {
template auto operator()(u) -> bk requires bc;
};
y bn;
} // namespace bg
} // namespace al
void b() {
a::ak t{4};
for (auto e : t | al::bg::bn)
;
}
[Bug c++/87748] [8 Regression] G++-8 treats SFINAE as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2018-10-25 00:00:00 |2019-4-16
Known to fail|9.0 |
--- Comment #6 from Jonathan Wakely ---
Another reproducer from PR 90080:
struct false_type { static constexpr bool value = false; };
struct true_type { static constexpr bool value = true; };
template struct enable_if { };
template struct enable_if { using type = T; };
template T&& declval();
template
struct is_static_castable : false_type
{};
template
struct is_static_castable(declval()))> :
true_type
{};
template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return static_cast(from);
}
template::value, int>::type = 0>
To* safePtrCast(From* from)
{
return dynamic_cast(from);
}
struct BarBase{ virtual ~BarBase() = default;};
struct Bar : virtual BarBase{};
Bar* foo(BarBase* b){
return safePtrCast(b);
}
90080.cc: In instantiation of ‘struct is_static_castable’:
90080.cc:21:57: required by substitution of ‘template::value), int>::type
> To* safePtrCast(From*) [with To = Bar; From = BarBase; typename
enable_if<(! is_static_castable::value), int>::type =
]’
90080.cc:31:30: required from here
90080.cc:12:42: error: cannot convert from pointer to base class ‘BarBase’ to
pointer to derived class ‘Bar’ because the base is virtual
12 | struct is_static_castable(declval()))>
: true_type
| ^~~~
90080.cc:12:42: error: cannot convert from pointer to base class ‘BarBase’ to
pointer to derived class ‘Bar’ because the base is virtual
90080.cc: In instantiation of ‘To* safePtrCast(From*) [with To = Bar; From =
BarBase; typename enable_if::value, int>::type
= 0]’:
90080.cc:31:30: required from here
90080.cc:18:12: error: cannot convert from pointer to base class ‘BarBase’ to
pointer to derived class ‘Bar’ because the base is virtual
18 | return static_cast(from);
|^~
[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #4 from Jonathan Wakely ---
Possible fix:
--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -220,11 +220,11 @@ namespace __debug
~vector() = default;
#endif
+#if __cplusplus < 201103L
/// Construction from a normal-mode vector
vector(const _Base& __x)
: _Base(__x) { }
-#if __cplusplus < 201103L
vector&
operator=(const vector& __x)
{
@@ -234,6 +234,11 @@ namespace __debug
return *this;
}
#else
+ /// Construction from a normal-mode vector
+ template>>
+vector(const _Up& __x)
+: _Base(__x) { }
+
vector&
operator=(const vector&) = default;
We'd want to do the same for all the other debug mode containers too.
[Bug libstdc++/90102] Incorrect ambiguous overload with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
--- Comment #5 from Jonathan Wakely ---
I'll come back to this for GCC 10.
Slightly better (and not broken) patch:
--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -220,11 +220,11 @@ namespace __debug
~vector() = default;
#endif
+#if __cplusplus < 201103L
/// Construction from a normal-mode vector
vector(const _Base& __x)
: _Base(__x) { }
-#if __cplusplus < 201103L
vector&
operator=(const vector& __x)
{
@@ -234,6 +234,12 @@ namespace __debug
return *this;
}
#else
+ /// Construction from a normal-mode vector
+ template, _Base>>>
+ vector(const _Up& __x)
+ : _Base(std::forward<_Base>(__x)) { }
+
vector&
operator=(const vector&) = default;
[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Wakely --- (In reply to Tony E Lewis from comment #4) > Are these arguments unpersuasive? IMHO yes. Comparison that only work with non-const objects are just bad comparison functions. They are unusable with maps and sets, because in a const-qualified member function they might be passed const arguments. They risk modifying their arguments, which leads to undefined behaviour. In your specific example, taking the arguments by reference might be less efficient than taking ints by value, so pessimizes the code. Requiring comparison objects to be usable as-const and with-const (i.e. when the comparison function object itself is const, and when the arguments are const) leads to fewer surprises, and is not especially difficult. The C++ working draft has been changed to make this program undefined, and I'm not inclined to make it Just Work.
[Bug target/88809] do not use rep-scasb for inline strlen/memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-16
Ever confirmed|0 |1
--- Comment #5 from Martin Liška ---
I would like working on this problem. I've read the Peters very detail analysis
on Stack overflow and I have first couple of questions and observations I've
did:
1) I would suggest to remove usage of 'rep scasb' at all; even for -Os the
price paid is quite huge
2) I've made strlen instrumentation for -fprofile-{generate,use} and collected
SPEC2016 statistics for train runs:
Benchmark strlen calls executed strlen calls total
executions avg. strlen
400.perlbench102 39 2358804
10.97
401.bzip2 00 0
403.gcc 144 21 4081
9.3
410.bwaves 00 0
416.gamess 00 0
429.mcf00 0
433.milc 30 0
434.zeusmp 00 0
435.gromacs 86792
12.46
436.cactusADM110 46 61788
10.61
437.leslie3d 00 0
444.namd 00 0
445.gobmk 417 75196
2.01
447.dealII 30 0
450.soplex 86 1161517
25.59
453.povray67 25 54584
33.25
454.calculix 540 0
456.hmmer 93 1052
15.1
458.sjeng 00 0
459.GemsFDTD 00 0
462.libquantum 00 0
464.h264ref 121 1
14274.0
465.tonto 00 0
470.lbm00 0
471.omnetpp 50 15 24291732
9.79
473.astar 00 0
481.wrf 42 15 20490
9.41
482.sphinx3 23 11402963
1.61
483.xalancbmk 273 160
13.04
Columns: Benchmark name, # of strlen calls in the benchmarks, # of strlen calls
that were called
during train run, total number of strlen execution, average strlen
Note: 14274.0 value for 464.h264ref is correct:
content_76 = GetConfigFileContent (filename_53);
_7 = strlen (content_76);
Based on the numbers an average string for which a strlen is called is quite
short (<32B).
3) The assumption that most strlen arguments have a known 16B alignment is
quite optimistic.
As mentioned, {c,}alloc returns a memory aligned to that, but strlen is most
commonly called
for a generic character pointer for which we can't prove the alignment.
4) Peter's suggested ASM expansion assumes such alignment. I expect a bit more
complex
code for a general alignment situation?
5) strlen call has the advantage then even though being compiled with -O2
-march=x86-64 (a distribution options),
the glibc can use ifunc to dispatch to an optimized implementation
6) The decision code in ix86_expand_strlen looks strange to me:
bool
ix86_expand_strlen (rtx out, rtx src, rtx eoschar, rtx align)
{
rtx addr, scratch1, scratch2, scratch3, scratch4;
/* The generic case of strlen expander is long. Avoid it's
expanding unless TARGET_INLINE_ALL_STRINGOPS. */
if (TARGET_UNROLL_STRLEN && eoschar == const0_rtx && optimize > 1
&& !TARGET_INLINE_ALL_STRINGOPS
&& !optimize_insn_for_size_p ()
&& (!CONST_INT_P (align) || INTVAL (align) < 4))
return false;
That explains why we generate 'rep scasb' for -O1.
My sugg
[Bug target/88809] do not use rep-scasb for inline strlen/memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #26 from Peter Bergner --- (In reply to Vladimir Makarov from comment #25) > (In reply to Peter Bergner from comment #24) >> I don't know why r0 isn't in profitable_regs for pseudo 116. > > Profitable regs there contain also conflict regs. R0 is conflicting with > p106. If R0 usage (in call insn) were in the same BB, your new conflict > calculation found that there is no actual conflict. But IRA uses > df-infrastructure which tells IRA that R0 lives at the BB end where p106 > occurs. I'm sorry, but I don't see where p116 conflicts with r0. Can you show me where/how? Looking at my IRA dump, I see: +++Allocating 40 bytes for conflict table (uncompressed size 48) ;; a0(r111,l0) conflicts: a2(r114,l0) a1(r113,l0) a3(r112,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; a1(r113,l0) conflicts: a0(r111,l0) a2(r114,l0) a3(r112,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; a2(r114,l0) conflicts: a0(r111,l0) a1(r113,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; a3(r112,l0) conflicts: a0(r111,l0) a1(r113,l0) a4(r117,l0) ;; total conflict hard regs: 0 12 14 ;; conflict hard regs: 0 12 14 ;; a4(r117,l0) conflicts: a3(r112,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; a5(r116,l0) conflicts: cp0:a0(r111)<->a4(r117)@330:move cp1:a2(r114)<->a3(r112)@41:shuffle cp2:a3(r112)<->a5(r116)@125:shuffle pref0:a0(r111)<-hr0@2000 pref1:a4(r117)<-hr0@660 pref2:a5(r116)<-hr0@1000 regions=1, blocks=6, points=10 allocnos=6 (big 0), copies=3, conflicts=0, ranges=6 Note: I'm assuming we're missing a \n after p116's empty conflicts above? So I don't see p116 conflict with r0, but I do see we register a shuffle between p112 and p116 and p112 does (correctly) conflict with r0. Is it really the shuffle between p112 and p116 that is preventing us from putting r0 into p116's profitable regs in the hope the p112 and p116 may get assigned the same reg allowing the removal of the copy? If so, that shuffle, since it's attached to the setting of the CC reg cannot actually be removed even if p112 and p116 are assigned the same register. Should we just ignore those types of shuffles/copies that have other side effects?
[Bug go/90116] New: Segmentation fault and what appears to be an implementation error in gofrontend (parse.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116
Bug ID: 90116
Summary: Segmentation fault and what appears to be an
implementation error in gofrontend (parse.cc)
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: 22374604 at sun dot ac.za
CC: cmang at google dot com
Target Milestone: ---
Created attachment 46179
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46179&action=edit
Program that causes segmentation fault
My research entails systematic generation of test cases from grammars. We
picked the golang from the antlr v4 grammar repository, avilable at
https://github.com/antlr/grammars-v4,which is a translation from the golang
language specification available at https://golang.org/ref/spec . Here I
present two issues I uncovered.
1. The following generated programs causes internalcompiler error:
package A; var A[A] A;
Compilation of the above program:
gccgo-8.2 -c -Wall -Wextra
/home/max/experiments/go/pos/pair/4730a8a0-603a-11e9-b473-8f102747f394.go
output:
gccgo-8.2: internal compiler error: Segmentation fault signal terminated
program go1
2. Implementation error of the parser in gcc/go/gofrontend/parse.cc
ggc-go also throws a syntax error on one of the generated programs below:
package A; const(B; C;);
Antlr v4 consumes the program correctly without throwing out any parse errors
and gccgo-8.2 compalins that '=' is expected.
One rule is of interest
ConstSpec = IdentifierList [ [ CompleteType ] "=" ExpressionList ] .
The above rule is from golang language specification and also included
commented in file parse.cc at line 1440 the method that implements the rule
follows at 1442. And it shows that '=' is optional. The go compiler implements
the hand written recursive descent parser. I came to think that the parser in
the gccgo does not implement the grammar (language spec) .
Rules involving that program to show its syntax is valid:
ConstDecl = "const" ( ConstSpec | "(" { ConstSpec ";" } ")" ) .
ConstSpec = IdentifierList [ [ CompleteType ] "=" ExpressionList ] .
IdentifierList = identifier { "," identifier } .
[Bug go/90116] Segmentation fault and what appears to be an implementation error in gofrontend (parse.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116 --- Comment #1 from Moeketsi Raselimo <22374604 at sun dot ac.za> --- Created attachment 46180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46180&action=edit gccgo-8.2 throws syntax error on this one
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #14 from Marek Polacek ---
The problem is that here
24072 /* Instantiate a dynamic exception-specification. noexcept will be
24073 handled below. */
24074 if (tree raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE
(code_pattern)))
24075 if (TREE_VALUE (raises))
24076 {
24077 specs = tsubst_exception_specification (TREE_TYPE
(code_pattern),
24078 args, tf_error,
NULL_TREE,
24079 /*defer_ok*/false);
raises is NOEXCEPT_EXPR<{}>, but its TREE_VALUE is null, so we don't
substitute.
[Bug target/84369] test case gcc.dg/sms-10.c fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369 --- Comment #5 from pthaugen at gcc dot gnu.org --- Author: pthaugen Date: Tue Apr 16 15:58:02 2019 New Revision: 270394 URL: https://gcc.gnu.org/viewcvs?rev=270394&root=gcc&view=rev Log: PR target/84369 * config/rs6000/power9.md: Add store forwarding bypass. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/power9.md
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #50 from Jakub Jelinek ---
(In reply to Florian Weimer from comment #49)
> (In reply to Bernd Edlinger from comment #48)
> > (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 don't think the target pragma/attribute is supported in Ada.
>
>pragma Machine_Attribute (Subprogram, "target", "general-regs-only");
>
> appears to be ignored (even if I use a string which would be accepted by the
> C/C++ pragma for that target, and not "general-regs-only". But it's been
> years since I did much Ada programming.
I don't understand why we are discussing Ada, because gcc/ada/raise_gcc.c, the
TU containing the Ada personality routine, is written in C.
The only problem is the D personality routine, which is written in D. And in
that case IMHO we can just use -mgeneral-regs-only on the command line for arm
in the Makefiles or something similar.
[Bug libstdc++/90105] std::forward_list::sort() is not "stable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-16 Ever confirmed|0 |1
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #27 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #26)
> ;; a4(r117,l0) conflicts: a3(r112,l0)
> ;; total conflict hard regs:
> ;; conflict hard regs:
>
> ;; a5(r116,l0) conflicts: cp0:a0(r111)<->a4(r117)@330:move
> cp1:a2(r114)<->a3(r112)@41:shuffle
> cp2:a3(r112)<->a5(r116)@125:shuffle
> pref0:a0(r111)<-hr0@2000
> pref1:a4(r117)<-hr0@660
> pref2:a5(r116)<-hr0@1000
> regions=1, blocks=6, points=10
> allocnos=6 (big 0), copies=3, conflicts=0, ranges=6
>
> Note: I'm assuming we're missing a \n after p116's empty conflicts above?
The code is
fputs (" conflicts:", file);
n = ALLOCNO_NUM_OBJECTS (a);
for (i = 0; i < n; i++)
{
ira_object_t obj = ALLOCNO_OBJECT (a, i);
ira_object_t conflict_obj;
ira_object_conflict_iterator oci;
if (OBJECT_CONFLICT_ARRAY (obj) == NULL)
continue;
[...]
}
and the
;; total conflict hard regs:
etc. prints are in that [...].
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #28 from Peter Bergner --- Vlad, in looking at add_insn_allocno_copies(), it looks like it relies on seeing REG_DEAD notes on whether to record a copy/shuffle that should be handled. Shouldn't we instead be looking at whether the source and destination regs conflict or not? Ie, there might not be a REG_DEAD note, but that doesn't mean the two regs/pseudos conflict. And conversely, if there is a REG_DEAD note on the copy/shuffle, the two regs/pseudos still could conflict.
