[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-25 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Alan Modra --- Created attachment 43236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43236&action=edit proposed patch patch under test
[Bug target/84033] New: powerpc64le -moptimize-swaps bad code with vec_vbpermq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033 Bug ID: 84033 Summary: powerpc64le -moptimize-swaps bad code with vec_vbpermq Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- Created attachment 43235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43235&action=edit testcase The attached testcase fails on ppc64le with -O2 -mcpu=power8, and passes when -mno-optimize-swaps is used.
[Bug c++/83211] Warning: ignoring incorrect section type for .init_array.00200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83211 Oleg Endo changed: What|Removed |Added Target||rx*-*-* arm*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-25 CC||olegendo at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.4.1 --- Comment #1 from Oleg Endo --- I can confirm this. It also happens on RX. I get: ltrans23.s: .section.init_array.00101,"aw",@progbits ltrans29.s: .section.init_array,"awx",@init_array It seems it also does not preserve the section flags as defined by INIT_ARRAY_SECTION_ASM_OP, CTORS_SECTION_ASM_OP etc. (Although the "w" flag in case of RX looks strange).
[Bug other/68239] libbacktrace allocation is sometimes very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68239 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Should be fixed.
[Bug target/84032] New: ICE in optimize_sc, at modulo-sched.c:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032
Bug ID: 84032
Summary: ICE in optimize_sc, at modulo-sched.c:1064
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu
gcc-8.0.0-alpha20180121 snapshot (r256935) ICEs when compiling the following
snippet w/ -mcpu=power6 (=power6x) -O1 -fmodulo-sched:
void
yr (int cm)
{
int ka = cm;
for (;;)
{
short int m0;
for (m0 = 0; m0 < 6; ++m0)
{
ka &= 1;
cm *= 2;
}
ka = (ka == 0) ? cm : 0;
}
}
% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180121 -mcpu=power6 -O1
-fmodulo-sched -c xjqb9y7g.c
during RTL pass: sms
xjqb9y7g.c: In function 'yr':
xjqb9y7g.c:18:1: internal compiler error: in optimize_sc, at
modulo-sched.c:1064
}
^
0x149a578 optimize_sc
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/modulo-sched.c:1064
0x149a578 sms_schedule
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/modulo-sched.c:1629
0x149a642 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/modulo-sched.c:3345
[Bug other/68239] libbacktrace allocation is sometimes very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68239 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Thu Jan 25 02:24:45 2018 New Revision: 257039 URL: https://gcc.gnu.org/viewcvs?rev=257039&root=gcc&view=rev Log: PR other/68239 * mmap.c (backtrace_free_locked): Don't put more than 16 entries on the free list. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/mmap.c
[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Michael Meissner --- Fixed in subversion id 257038.
[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550 --- Comment #9 from Michael Meissner --- Author: meissner Date: Thu Jan 25 01:09:19 2018 New Revision: 257038 URL: https://gcc.gnu.org/viewcvs?rev=257038&root=gcc&view=rev Log: [gcc/testsuite] 2018-01-24 Michael Meissner PR target/81550 * gcc.target/powerpc/loop_align.c: Use unsigned long for the loop index instead of int, which allows IVOPTs to properly optimize the loop. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/loop_align.c
[Bug c++/84031] New: structured binding unpacks nameless padding bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84031
Bug ID: 84031
Summary: structured binding unpacks nameless padding bitfields
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: will at dash dot org
Target Milestone: ---
In g++ >= 7.1.0 nameless bitfields are unpacked in structured binding
declarations.
GCC compiles this code with no error or warning.
using uint8_t = unsigned char;
struct bits8 { uint8_t :1, b1:1, b23:2, :1, b567:3; };
static_assert(sizeof(bits8)==1);
int main()
{
static constexpr bits8 byte{1,2,3};
const auto& [b0,b1,b23,b4,b567] = byte;
static_assert(b1==1 && b23==2 && b567==3);
static_assert(b0==0 && b4==0);
}
Clang, on the other hand, does not accept this code - it chooses not to unpack
nameless bitfields (Clang error: type 'const bits8' decomposes into 3 elements,
but 5 names were provided).
GCC errors on this code which clang accepts:
int main()
{
static constexpr bits8 byte{1,2,3};
const auto& [b1,b23,b567] = byte;
static_assert(b1==1 && b23==2 && b567==3);
}
GCC error: only 3 names provided for structured binding
const auto& [b1,b23,b567] = byte;
^
note: while 'const bits8' decomposes into 5 elements
I believe that g++ behavior is incorrect. The intent is for the binding
declarations to match identifiers. This interpretation is symmetrical with the
braced-init-list where at most 3 values can be specified to initialize only the
named bitfield members. The nameless ones are passed over...
[Bug c++/83950] [8 regression] error: no matching function for call to ‘folly::dynamic::at(size_t&) const’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83950 --- Comment #3 from Sunil Pandey --- I shouldn't say it's bug, sorry about that. Just application build regression from GCC 7 to GCC 8. Looks like creduce reduced this test case too much in this case.
[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #6 from David Malcolm --- Does r257037 fix this for you? Thanks.
[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Thu Jan 25 00:45:51 2018 New Revision: 257037 URL: https://gcc.gnu.org/viewcvs?rev=257037&root=gcc&view=rev Log: Fix jit.dg/test-alignment* (PR jit/82846) These testcases jit-compile functions that return char, but were erroneously calling them as if they returned int. This led to errors for certain target configurations (e.g. reading from %eax (32-bit) in the harness when only %al (8-bit) had been written to in the jit-compiled function). gcc/testsuite/ChangeLog: PR jit/82846 * jit.dg/test-alignment.c (create_aligned_code): Fix return type of "fn_type" typedef. * jit.dg/test-alignment.cc (verify_aligned_code): Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/jit.dg/test-alignment.c trunk/gcc/testsuite/jit.dg/test-alignment.cc
[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #7 from Segher Boessenkool --- It is first V2DI in the RTL, which exists just fine (but there is no such divide insn); then when it is split to two DImode divides, it just generates div:DI etc., which does not exist for -m32. So we either should do what is done for a DImode divides during expand there, or not allow this builtin.
[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #20 from Joseph S. Myers --- Fixed for GCC 8.
[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 --- Comment #19 from Joseph S. Myers --- Author: jsm28 Date: Wed Jan 24 23:36:29 2018 New Revision: 257032 URL: https://gcc.gnu.org/viewcvs?rev=257032&root=gcc&view=rev Log: Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467). PR target/68467 is libgcc failing to build for m68k-linux-gnu configured for ColdFire. Jeff has an analysis in the PR identifying the problem as resulting from the callers of libcalls with 1-byte or 2-byte arguments wanting to push just 1 or 2 bytes on the stack, while the libcall implementations have the normal C ABI and expect 4-byte arguments. For normal C functions, I believe the TARGET_PROMOTE_PROTOTYPES definition would ensure such arguments get passed as 4-byte, but that does not apply for libcalls. This patch fixes the issue by defining TARGET_PROMOTE_FUNCTION_MODE for m68k. The definition is conservative, only applying promotions in the case of arguments to libcalls; otherwise it returns the unpromoted type, which I believe matches what the default implementation of the hook would have done on m68k. I have tested that this fixes the libgcc build for ColdFire, and, in conjunction with one glibc patch, this enables glibc to build cleanly for ColdFire and to pass the compilation parts of the glibc testsuite except for one test unrelated to this patch (while glibc and the compilation parts of the testsuite continue to build OK for non-ColdFire m68k, as expected). I have *not* run any GCC tests for this patch, or any execution tests for m68k. PR target/68467 * config/m68k/m68k.c (m68k_promote_function_mode): New function. (TARGET_PROMOTE_FUNCTION_MODE): New macro. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.c
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Version|4.7.0 |4.7.1 Resolution|--- |FIXED Target Milestone|--- |5.4 --- Comment #12 from kargl at gcc dot gnu.org --- I did not realize that there was a PR about this issue. I changed gfortran behavior to give what I expected user want in 7-branch prior to branching r245255 | kargl | 2017-02-07 13:28:08 -0800 (Tue, 07 Feb 2017) | 6 lines 2017-02-04 Steven G. Kargl * trans-types.c (gfc_get_int_kind_from_width_isofortranen): Choose REAL type with the widest precision if two (or more) have the same storage size. I back ported the fix to both 5-branch (r24526) and 6-branch (r245259). I don't have 5.xx installed, but 6, 7, and 8 give % cat a.f90 use iso_fortran_env real(real32) a real(real64) b real(real128) c print *, kind(a), kind(b), kind(c) print *, digits(a), digits(b), digits(c) end % gfc6 -o z a.f90 && ./z 4 8 16 24 53 113 % gfc7 -o z a.f90 && ./z 4 8 16 24 53 113 % gfcx -o z a.f90 && ./z 4 8 16 24 53 113 So, I'm closing this as fixed (almost a year ago :-)
[Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #4 from Jakub Jelinek --- (In reply to paul.richard.tho...@gmail.com from comment #3) > OK for trunk? Ok, thanks.
[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #6 from Bill Schmidt --- But I assume that's your transcription error. In the test case the arguments are vector long long.
[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #5 from Bill Schmidt --- That looks completely invalid, the args should be vector long long, not long long.
[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 --- Comment #4 from Jeffrey A. Law --- Author: law Date: Wed Jan 24 21:57:16 2018 New Revision: 257031 URL: https://gcc.gnu.org/viewcvs?rev=257031&root=gcc&view=rev Log: PR target/83994 * i386.c (get_probe_interval): Move to earlier point. (ix86_compute_frame_layout): If -fstack-clash-protection and the frame is larger than the probe interval, then use pushes to save registers rather than reg->mem moves. (ix86_expand_prologue): Remove conditional for int_registers_saved assertion. PR target/83994 * gcc.target/i386/pr83994.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr83994.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-01/msg02059.ht ||ml Last reconfirmed||2018-01-24 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Peter Bergner --- Patch submitted to fix this and PR56010.
[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-24
CC||law at redhat dot com
Ever confirmed|0 |1
--- Comment #5 from Jeffrey A. Law ---
In the reduced testcase we have:
;; basic block 3, loop depth 1, count 10737436510031 (estimated locally),
maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred: 2 [always] count:1073741826 (estimated locally)
(FALLTHRU,EXECUTABLE)
;;5 [always] count:10737436510031 (estimated locally)
(FALLTHRU,DFS_BACK,EXECUTABLE)
# da_6 = PHI <0B(2), _7(5)>
_5 = operator new (8, db_4(D));
MEM[(struct &)_5] ={v} {CLOBBER};
_8 = &MEM[(struct e *)_5].cm;
a::d::e::cq (_5);
_9 = a::d::e::co (_5);
a::d::e::cl::cl (_8, _9, D.3228);
cp_10 = da_6->cm.r;
if (cp_10 != 0B)
goto ; [53.47%]
else
goto ; [46.53%]
THe warning seems warranted to me. The location as has been pointed out in
other comments is totally bogus.
Similarly for the full testcase:
;; basic block 4, loop depth 1
;;pred: 3
;;7
# __first$_M_current_2 = PHI <0B(3), _47(7)>
# __cur_38 = PHI <_50(3), __cur_48(7)>
MEM[(struct &)__cur_38] ={v} {CLOBBER};
_41 = &__cur_38->D.22571._M_local_buf;
MEM[(struct &)__cur_38] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)__cur_38]._M_p = _41;
_42 = MEM[(const struct basic_string *)__first$_M_current_2];
_43 = &MEM[(const struct basic_string
*)__first$_M_current_2].D.22571._M_local_buf;
if (_42 == _43)
goto ; [30.00%]
else
goto ; [70.00%]
;;succ: 5
;;6
[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #4 from David Malcolm --- It's a bug in the testcases; am testing a fix now.
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #7 from Bill Long --- Thanks - very helpful information. I'll try to find out what version of gcc was used to build their library.
[Bug middle-end/84024] [8 Regression] internal compiler error: in operator>, at profile-count.h:855
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84024 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law --- Almost certainly a duplicate. *** This bug has been marked as a duplicate of bug 83055 ***
[Bug tree-optimization/83055] [8 Regression] ICE in operator>, at profile-count.h:834
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83055 Jeffrey A. Law changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #7 from Jeffrey A. Law --- *** Bug 84024 has been marked as a duplicate of this bug. ***
[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #4 from Will Schmidt --- I'm having a moment of doubt on the validity of the testcases involved here. vector long long a = vec_div(long long b, long long c); Any chance that is invalid for -m32 ? I don't see a whole lot of vec_div() references in the test suite with long long types. I don't see it called out in the ABI, but the VSX_BUILTIN_DIV_V2DI and VSX_BUILTIN_UDIV_V2DI do seem to exist.
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #6 from Dominique d'Humieres --- Note that I got a Internal Error: stash_internal_unit(): Stack Size Exceeded when using mismatched gfortran 7.2.0 and omp_lib.mod.
[Bug c++/84030] New: Name lookup in presence of namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84030
Bug ID: 84030
Summary: Name lookup in presence of namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Zahira.Ammarguellat at intel dot com
Target Milestone: ---
In the code snippet below gcc doesn't give any diagnostics:
struct A_ { };
namespace N_ {
struct A_ {
int g()
{
return 3;
}
template operator T()
{
return T();
}
};
}
int main(int argc, char *argv[])
{
N_::A_ a;
int b = a.operator A_().g();
return b == 3;
}
gcc seems to be choosing "N_::A_::A_" operator. But in reality there should be
ambiguity between that and A::operator?
Both clang and MSVC fail to disambiguate it.
See https://godbolt.org/#
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #5 from Bill Long --- I tried on my Mac laptop (gcc version 6.3.0) and it also works there. Evidently not a representative test. The differences I see between that environment and the original customer's is that they are running 7.2.0, using srun (SLURM) for program launch, and running on Broadwell processors. The original error Internal Error: stash_internal_unit(): Stack Size Exceeded suggests some issue with running out of memory.
[Bug target/84010] [sparc64] Problematic TLS code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010 --- Comment #6 from Richard Henderson --- For better rematerialization, I wonder if it wouldn't be better to represent this as (set (reg:P tmp) (const:P (unspec [(symbol_ref "xxx")] UNSPEC_TLSIE))) prior to reload, and split to sethi+add+ld only after reload. That makes the rhs CONSTANT_P, which gets us into the right sort of paths in lra and reload. It also means we'll never spill just part of the expression.
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #4 from Dominique d'Humieres --- > What happens with 16 threads? % gfc -fopenmp pr83948.f90 % setenv OMP_NUM_THREADS 16 % ./a.out Table element number = 995 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 995 Indexval*2=1990 RandomValue=0.899732, RandomValue*999=898, iThread= 15 Table element number = 996 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 996 Indexval*2=1992 RandomValue=0.445212, RandomValue*999=444, iThread= 15 Table element number = 997 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 997 Indexval*2=1994 RandomValue=0.839072, RandomValue*999=838, iThread= 15 Table element number = 998 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 998 Indexval*2=1996 RandomValue=0.242375, RandomValue*999=242, iThread= 15 Table element number = 999 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 999 Indexval*2=1998 RandomValue=0.579442, RandomValue*999=578, iThread= 15 Table element number = 1000 Same pole re-projecting area source: Beginnng of new record: : IndexVal=1000 Indexval*2=2000 RandomValue=0.300305, RandomValue*999=300, iThread= 15
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #3 from Bill Long --- What happens with 16 threads?
[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #3 from Will Schmidt --- (In reply to Bill Schmidt from comment #2) > Does this work on GCC 7 (obviously without -mno-fold-gimple)? If so, please > mark as [8 regression] in title. looks like No, this also fails on the gcc 7 branch. (the -mno-fold-gimple option, as well as the vec_div folding, were both added after gcc7 branched.) (On a Power7) # checkout svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch gcc-7-branch # configure ../../gcc-7-branch/configure --enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7 --disable-multilib --with-long-double-128 --prefix=/home/willschm/gcc/install/gcc-7-branch --disable-bootstrap # check version ~/gcc/build/gcc-7-branch> /home/willschm/gcc/build/gcc-7-branch/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/home/willschm/gcc/build/gcc-7-branch/gcc/xgcc Target: powerpc64-unknown-linux-gnu Configured with: ../../gcc-7-branch/configure --enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7 --disable-multilib --with-long-double-128 --prefix=/home/willschm/gcc/install/gcc-7-branch --disable-bootstrap Thread model: posix gcc version 7.2.1 20180124 (GCC) # run ~/gcc/build/gcc-7-branch> /home/willschm/gcc/build/gcc-7-branch/gcc/xgcc -B/home/willschm/gcc/build/gcc-7-branch/gcc/ /home/willschm/testme.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -ffat-lto-objects -S -o testme.o -m32 /home/willschm/testme.c: In function ‘main’: /home/willschm/testme.c:19:1: internal compiler error: in elimination_costs_in_insn, at reload1.c:3617 0x10699b5b elimination_costs_in_insn ../../../gcc-7-branch/gcc/reload1.c:3614 0x1069a3db calculate_elim_costs_all_insns() ../../../gcc-7-branch/gcc/reload1.c:1607 0x10537343 ira_costs() ../../../gcc-7-branch/gcc/ira-costs.c:2261 0x1052f443 ira_build() ../../../gcc-7-branch/gcc/ira-build.c:3420 0x10524187 ira ../../../gcc-7-branch/gcc/ira.c:5308 0x10524187 execute ../../../gcc-7-branch/gcc/ira.c:5619
[Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #3 from paul.richard.thomas at gmail dot com --- Hi Jakub, I have made the changes to the types of the dtype elements that you suggested. It led to a cast being needed in trans-intrinsic.c(gfc_conv_intrinsic_rank) but, apart from that, the changes were straightforward. Please find the updated patch attached. OK for trunk? Once I have committed this patch, I promise that I will stick to regressions and bug fixes through to release :-) Paul On 24 January 2018 at 09:11, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 > > Jakub Jelinek changed: > >What|Removed |Added > >Priority|P3 |P4 > Status|UNCONFIRMED |NEW >Last reconfirmed||2018-01-24 > CC||jakub at gcc dot gnu.org, >||pault at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #2 from Jakub Jelinek --- > Started with r254936. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug target/84014] [6/7/8 Regression] ICE in setup_min_max_allocno_live_range_point, at ira-build.c:2762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014 --- Comment #3 from Vladimir Makarov --- Author: vmakarov Date: Wed Jan 24 19:45:55 2018 New Revision: 257029 URL: https://gcc.gnu.org/viewcvs?rev=257029&root=gcc&view=rev Log: 2018-01-24 Vladimir Makarov PR target/84014 * ira-build.c (setup_min_max_allocno_live_range_point): Set up min/max for never referenced object. 2018-01-24 Vladimir Makarov PR target/84014 * gcc.target/powerpc/pr84014.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr84014.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira-build.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #13 from Pedro Alves --- Fix is now in GDB's master, 8.1, and 8.0 branches.
[Bug target/83845] [8 regression] new failures after r256620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83845 --- Comment #3 from rsandifo at gcc dot gnu.org --- FWIW, I now have patches that fix all the big-endian SVE failures. Hope to post them later this week.
[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug c++/83979] [8 Regression] ICE with pointer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83979 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #20 from Aldy Hernandez ---
Created attachment 43233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43233&action=edit
WIP that fixes PR, but causes other regressions
I am attaching a proof of concept hack that fixes this PR by moving the
optimize_bit_field_compare functionality from the front-end to the gimple
reassoc pass (picked at random, we could do it anywhere else).
It recognizes the following pattern:
_1 = some.bit_field;
if (_1 == 99)
...and converts it to a BIT_FIELD_REF + comparison.
Although it works for the PR, it creates various regressions, because it seems
fold_truth_andor can create optimized bit field comparisons as well, which
would be challenging to deconstruct later in gimple.
For example. Imagine this:
enum output_type
{
type_pde,
type_relocatable,
type_pie,
type_dll,
};
struct bfd_link_info
{
enum output_type type : 2;
};
void test_pic (struct bfd_link_info *info)
{
if info)->type == type_dll) || ((info)->type == type_pie)))
blah();
}
Thanks to fold_truth_andor (fold_range_test specifically), if we were to delay
optimize_bit_field_compare(), we would generate the following coming out of the
front-end:
if (info->type + 2 <= 1)
blah();
That is, not only have we merged the set of bit field comparisons, we have also
introduced an unsigned overflow to make the comparison simpler.
So now our gimple optimize bit field compare function would also have to deal
with this:
_1 = info_7(D)->type;
_2 = _1 + 2;
if (_2 <= 1)
and perhaps convert it to:
_5 = BIT_FIELD_REF <*info, 8, 0>
_6 = (_5 + 2) & 3
if (_6 <= 1)
My worry is that we can handle optimizations of the following quite easily
(attached patch):
_1 = some.bit_field;
if (_1 == 99)
but with things like the following, it starts getting harder and harder:
_1 = info_7(D)->type;
_2 = _1 + 2;
if (_2 <= 1)
And I'm pretty sure fold_truth_andor() has a lot more tricks up its sleeve,
that we'll have to mop up in gimple. All in all, I doubt we can sensibly move
optimize_bit_field_compare() to the middle end, without having to bend over
backwards to reconstruct things or port some of fold_truth_andor() to the
middle end as well. I doubt this is stage4 material.
I can certainly teach my WIP to handle the _2 = _1 + 2 case above without
porting fold_truth_andor*() to the middle end, but I'm afraid this is just one
of the many scenarios we'll have to deal with. I could be wrong, and could
certainly take a stab at it.
Oh, and I'm completely ignoring the reassocation suggestions Jakub makes in
comment 19. That would make even more work for stage4 :).
Thoughts?
[Bug middle-end/84029] New: Partially inline strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84029 Bug ID: 84029 Summary: Partially inline strcmp Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- Initial performance results for PR78809 suggest that partial inlining of strcmp may be beneficial. We could inline the first character comparison before calling strcmp: if ((res = s[0] - t[0]) == 0) res = strcmp (s, t); Such a check would have low overhead and improve performance if the first character often mismatches. Checking for more characters is possible, but would have a higher overhead. strncmp and memcmp could do something similar.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #10 from Steve Kargl --- n Wed, Jan 24, 2018 at 03:38:10PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > --- Comment #9 from Steve Kargl --- > On Wed, Jan 24, 2018 at 10:53:40AM +, guez at lmd dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > > > --- Comment #8 from Lionel GUEZ --- > > It does not seem completely true that gfortran makes no distinction between > > qNaN and sNaN. > > See comment #2. > To be clear. I'm not being dismissive, here. The bug report is still open because there is some agreement that how gfortran handles qNaN and sNaN needs to be revisited. The problem is that there are only a few individuals who actively contribute to gfortran development. There are currently 931 open bug reports. They may not have the time (or perhaps the interest in this issue) given the 930 other problems. If the problem is a significant roadblock for you, then getting involved with gfortran development would be most welcomed. You can ask questions on the fortran@ and gcc@ mailing list. Also, given your email address, you may be able to directly (as in person) discuss the IEEE 754 implementation with Francois-Xavier Coudert (although FX's contributions have diminished over time due to Real Life, ie., wife, kids, job, etc.).
[Bug target/84014] [6/7/8 Regression] ICE in setup_min_max_allocno_live_range_point, at ira-build.c:2762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014 --- Comment #2 from Vladimir Makarov --- Thank you for reporting. The problem occurs when only one subreg (obj) of register (allocno) is used in a function. I'll work on a patch.
[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||redi at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
creduced testcase:
namespace a {
typedef long unsigned c;
}
void *operator new(a::c, void *) noexcept;
template < typename f, f g > struct aa { static constexpr f h = g; };
typedef aa< bool, false > i;
template < bool, typename, typename > struct ab;
template < typename... > struct j;
template < typename k, typename ac > struct j< k, ac > : ab< 1, k, ac > {};
template < typename... > struct ad;
template < typename k, typename ac >
struct ad< k, ac > : ab< k::h, ac, k >::ae {};
template < typename l > struct af : aa< bool, !l::h > {};
struct m : i {};
template < typename f > struct n : j< m, f >::ae {};
struct ah {
template < typename > static aa< bool, true > ai(int);
};
template < typename f > struct aj : ah { typedef decltype(ai< f >(0)) ae; };
struct u : aj< int >::ae {};
struct v {
template < typename, typename > static aa< bool, true > ai(int);
};
template < typename f, typename o > struct x : v {
typedef decltype(ai< f, o >(0)) ae;
};
template < typename o > struct p : ad< u, x< int, o > > {};
template < typename f, typename > struct q : ab< n< f >::h, int, p< int > > {};
template < typename o > struct al : q< int, o >::ae {};
template < typename... > struct am;
template < typename f, typename o > struct am< f, o > : al< o > {};
template < typename, typename... an > struct ao : am< int, an... >::ae {};
struct aq : aa< bool, noexcept(int()) > {};
template < typename, typename... an > struct ar : ad< ao< int, an... >, aq >
{};
template < typename f > struct as : ar< f, f > {};
template < typename f > struct at : as< f > {};
template < bool, typename av, typename > struct ab { typedef av ae; };
template < typename av, typename aw > struct ab< false, av, aw > {
typedef aw ae;
};
template < typename ax > struct ay { using ae = ax; };
template < typename ax, template < typename > class > using ba = ay< ax >;
template < typename ax, template < typename > class az >
using bb = typename ba< ax, az >::ae;
template < typename f > f bc(f &bd) { return static_cast< f && >(bd); }
struct bf : ad< af< at< int > >, int > {};
template < typename > struct bg;
template < typename f > struct bg< f * > { typedef f bi; };
template < typename bk > class bl {
bk bm;
public:
typedef typename bg< bk >::bi &&bi;
bl(bk) : bm() {}
bi operator*() { return bi(*bm); }
void operator++() { ++bm; }
};
template < typename bk, typename bp = typename ab< bf::h, bk, bl< bk > >::ae >
bp bq(bk br) {
return br;
}
namespace bs {
struct bt {
static char bv(char *, char *, long);
};
}
namespace a {
struct bt : bs::bt {};
template < typename f > class allocator {
public:
typedef f bh;
template < typename > struct bw { typedef allocator bx; };
};
struct by {
template < typename f > struct bz {
using ae = typename f::template bw< int >::bx;
};
template < typename f > using ca = typename f::b;
};
template < typename cc, typename > using cd = typename by::bz< cc >::ae;
template < typename cc > struct ce : by {
using cb = bb< typename cc::bh *, ca >;
template < typename f > using cf = cd< cc, f >;
};
}
namespace bs {
template < typename cc > struct cg : a::ce< cc > {
template < typename > struct bw {
typedef typename a::ce< cc >::template cf< int > bx;
};
};
}
namespace a {
namespace d {
class e {
public:
typedef bt cj;
struct cl {
cl(bs::cg< bs::cg< allocator< char > >::bw< char >::bx >::cb,
allocator< char >);
bs::cg< bs::cg< allocator< char > >::bw< char >::bx >::cb r;
} cm;
char cn[];
bs::cg< bs::cg< allocator< char > >::bw< char >::bx >::cb co();
bool t() {
bs::cg< bs::cg< allocator< char > >::bw< char >::bx >::cb cp = cm.r;
return cp;
}
bs::cg< allocator< char > >::bw< char >::bx cq();
e(e &&cr) noexcept : cm(co(), cq()) {
if (cr.t())
cj::bv(cn, cn, 1);
}
};
}
template < typename cs, typename... an > void ct(cs *cu, an &&... cv) {
new (cu) cs(bc(cv)...);
}
struct cw {
template < typename cx, typename cy > static cy cz(cx da, cy) {
cy db;
try {
for (;; ++da)
ct(db, *da);
} catch (...) {
}
return db;
}
};
template < typename cx, typename cy > void dc(cx da, cx, cy de) {
cw::cz(da, de);
}
template < typename cx, typename cy, typename f >
void __uninitialized_copy_a(cx da, cx dd, cy de, f) {
dc(da, dd, de);
}
template < typename > struct df {
typedef allocator< d::e > dg;
typedef bs::cg< dg >::cb cb;
struct {
cb di;
cb dj;
} dl;
};
template < typename > class dm : df< allocator< d::e > > {
public:
void reserve();
templat
[Bug target/84028] [nvptx] nested-function-1.f90 hangs at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84028
Tom de Vries changed:
What|Removed |Added
Keywords||openacc
Target||nvptx
--- Comment #1 from Tom de Vries ---
Tentative patch adds an exit after $L27, and fixes the hang, both in the
minimal and original testcase:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index d8484120c9d..a6f444340fd 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4065,8 +4065,8 @@ nvptx_single (unsigned mask, basic_block from,
basic_block to)
else
{
rtx_insn *label_insn = emit_label_after (label, tail);
- if (mode == GOMP_DIM_VECTOR && CALL_P (tail)
- && find_reg_note (tail, REG_NORETURN, NULL))
+ if ((mode == GOMP_DIM_VECTOR || mode == GOMP_DIM_WORKER)
+ && CALL_P (tail) && find_reg_note (tail, REG_NORETURN, NULL))
emit_insn_after (gen_exit (), label_insn);
}
}
...
[Bug target/84028] New: [nvptx] nested-function-1.f90 hangs at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84028
Bug ID: 84028
Summary: [nvptx] nested-function-1.f90 hangs at -O1
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
These openacc fails are left on trunk:
...
WARNING: program timed out.
FAIL: libgomp.oacc-fortran/nested-function-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -O1 execution test
WARNING: program timed out.
FAIL: libgomp.oacc-fortran/nested-function-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -O2 execution test
FAIL: libgomp.oacc-fortran/nested-function-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions execution test
FAIL: libgomp.oacc-fortran/nested-function-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -O3 -g execution test
...
This minimal test-case hangs at GOMP_NVPTX_JIT=-O1 and higher:
...
program foo
integer :: a(3,3,3), k, kk, kkk, l, ll, lll
a = 1
!$acc parallel num_gangs(1) num_workers(2)
if (any(a(1:3,1:3,1:3).ne.1)) call abort
do ll=1,1
!$acc loop vector
do lll=1,1
a(1,1,1) = 2
enddo
enddo
if (a(1,1,1).ne.2) call abort
!$acc end parallel
end program foo
...
We generate for the abort:
...
$L4:
@ %r56 bra.uni $L27;
@ %r57 bra $L28;
{
call _gfortran_abort;
trap;
exit;
}
$L28:
exit;
$L27:
...
This is similar to PR81352, but for workers. The neutered workers start
executing random code after $L27.
[Bug fortran/82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Target issue?
[Bug fortran/82007] DTIO write format stored in a string leads to severe errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82007 --- Comment #9 from Dominique d'Humieres --- > Should I backport this to 7? IMO yes.
[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Works for me on x86_64-apple-darwin17 on a corei7 (4 cores, 8 threads): Table element number = 995 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 995 Indexval*2=1990 RandomValue=0.985833, RandomValue*999=984, iThread= 19 Table element number = 996 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 996 Indexval*2=1992 RandomValue=0.939807, RandomValue*999=938, iThread= 19 Table element number = 997 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 997 Indexval*2=1994 RandomValue=0.747089, RandomValue*999=746, iThread= 19 Table element number = 998 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 998 Indexval*2=1996 RandomValue=0.795734, RandomValue*999=794, iThread= 19 Table element number = 999 Same pole re-projecting area source: Beginnng of new record: : IndexVal= 999 Indexval*2=1998 RandomValue=0.367872, RandomValue*999=367, iThread= 19 Table element number = 1000 Same pole re-projecting area source: Beginnng of new record: : IndexVal=1000 Indexval*2=2000 RandomValue=0.324235, RandomValue*999=323, iThread= 19
[Bug target/83368] alloca after setjmp breaks PIC base reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368 --- Comment #19 from James Clarke --- Thanks for the fix; is this a candidate for backporting to the gcc-7 branch? If not we can just carry it in Debian, but it would be nicer to have it upstream.
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #12 from Pedro Alves --- GDB fix posted here: https://sourceware.org/ml/gdb-patches/2018-01/msg00482.html
[Bug fortran/83939] Constraint C1290 (elemental function cannot be allocatable) not enforced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83939 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug c++/83692] Rejects valid constexpr with unrelated code fixing problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692 --- Comment #4 from Marek Polacek --- Seems like in C++17 the condition in if (m_x.value() != 1) throw 0; gets evaluated to 1 instead of 0, so we try to evaluate the "throw 0" but that can't be evaluated to a constant value. Maybe some bad caching in constexpr_call_cache.
[Bug fortran/83980] Various issues with character length in array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83980 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- The ICEs have replaced with errors between revisions r256574 (2018-01-12, ICE) and r256917 (2018-01-20, errors). What is surprising is that pr83823 uses a similar construct, but does not give any error.
[Bug fortran/83823] [8 Regression] Character length issues with PACK()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83823 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The change occurred between revisions r253982 (2017-10-22, OK) and r254227 (2017-10-30, wrong code).
[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990 --- Comment #3 from Tony E Lewis --- Just to be clear... I don't think it's _necessarily_ a problem that the warning is being triggered in this particular context (because I'm not in a position to judge that). The core problem I wish to highlight is that, despite being triggered within a system header, the warning isn't being silenced as I would expect. And my suspicion is that this is caused by the source location info having been lost so the location cannot be recognised as within a system header (as has been hypothesised for bug 83591). (I also wish to highlight that the lack of source location info makes the warning very much harder to respond to.)
[Bug c++/84027] New: new-expression does not accept an attribute-specifier-seq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84027
Bug ID: 84027
Summary: new-expression does not accept an
attribute-specifier-seq
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: smw at gcc dot gnu.org
Target Milestone: ---
The standard [expr.new]/1 defines the new-type-id part of a new expression as
having (one or more) attribute-specifier-seq but GCC does not accept that
construct. Example code:
void f() { char* p = new char[sizeof(int)] alignas(int); }
GCC 8.0.1 20180117 (exprimental) with -std=c++14 -pedantic gives the following
diagnostic.
: In function 'void f()':
1 : :1:44: error: expected ',' or ';' before 'alignas'
void f() { char* p = new char[sizeof(int)] alignas(int); }
^~~
1 : :1:18: warning: unused variable 'p' [-Wunused-variable]
void f() { char* p = new char[sizeof(int)] alignas(int); }
^
Note that the example code is accepted without error by clang and ICC.
[Bug c++/82514] [8 Regression] ICE: in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82514
--- Comment #5 from Jason Merrill ---
Further reduced:
template void i(h) { }
template void n() {
[] {
struct p { };
i(p{});
};
}
auto f = n<1>;
[Bug middle-end/83977] [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83977 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Jan 24 16:28:47 2018 New Revision: 257023 URL: https://gcc.gnu.org/viewcvs?rev=257023&root=gcc&view=rev Log: PR middle-end/83977 * tree.c (free_lang_data_in_decl): Don't clear DECL_ABSTRACT_ORIGIN here. * omp-low.c (create_omp_child_function): Remove "omp declare simd" attributes from DECL_ATTRIBUTES (decl) without affecting DECL_ATTRIBUTES (current_function_decl). * omp-simd-clone.c (expand_simd_clones): Ignore DECL_ARTIFICIAL functions with non-NULL DECL_ABSTRACT_ORIGIN. * c-c++-common/gomp/pr83977-1.c: New test. * c-c++-common/gomp/pr83977-2.c: New test. * c-c++-common/gomp/pr83977-3.c: New test. * gfortran.dg/gomp/pr83977.f90: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr83977-1.c trunk/gcc/testsuite/c-c++-common/gomp/pr83977-2.c trunk/gcc/testsuite/c-c++-common/gomp/pr83977-3.c trunk/gcc/testsuite/gfortran.dg/gomp/pr83977.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/omp-simd-clone.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug c++/83979] [8 Regression] ICE with pointer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83979
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Wed Jan 24 16:22:30 2018
New Revision: 257021
URL: https://gcc.gnu.org/viewcvs?rev=257021&root=gcc&view=rev
Log:
Fix use of boolean_true/false_node (PR 83979)
r255913 changed some constant_boolean_node calls to boolean_true_node
and boolean_false_node, which meant that the returned tree didn't
always have the right type.
2018-01-24 Richard Sandiford
gcc/
PR tree-optimization/83979
* fold-const.c (fold_comparison): Use constant_boolean_node
instead of boolean_{true,false}_node.
gcc/testsuite/
PR tree-optimization/83979
* g++.dg/pr83979.c: New test.
Added:
trunk/gcc/testsuite/g++.dg/pr83979.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889
--- Comment #2 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Wed Jan 24 16:22:40 2018
New Revision: 257022
URL: https://gcc.gnu.org/viewcvs?rev=257022&root=gcc&view=rev
Log:
Remove explicit dg-do runs from gcc.dg/vect (PR 83889)
The failures in this PR were from forcing { dg-do run } even when
vect.exp chooses options that are incompatible with the runtime.
The default vect.exp behaviour is to execute when possible, so there's
no need for a dg-do at all.
The patch removes other unconditional { dg-do run }s too. Many of them
were already failing in the same way.
Also, the dg-do run condition in vect-reduc-or* seems unnecessary:
the test should run correctly whatever happens, and the scan tests
are already guarded properly.
2018-01-24 Richard Sandiford
gcc/testsuite/
PR testsuite/83889
* gcc.dg/vect/pr79920.c: Remove explicit dg-do run.
* gcc.dg/vect/pr80631-1.c: Likewise.
* gcc.dg/vect/pr80631-2.c: Likewise.
* gcc.dg/vect/pr81410.c: Likewise.
* gcc.dg/vect/pr81633.c: Likewise.
* gcc.dg/vect/pr81815.c: Likewise.
* gcc.dg/vect/pr82108.c: Likewise.
* gcc.dg/vect/pr83857.c: Likewise.
* gcc.dg/vect/vect-alias-check-8.c: Likewise.
* gcc.dg/vect/vect-alias-check-9.c: Likewise.
* gcc.dg/vect/vect-alias-check-10.c: Likewise.
* gcc.dg/vect/vect-alias-check-11.c: Likewise.
* gcc.dg/vect/vect-alias-check-12.c: Likewise.
* gcc.dg/vect/vect-reduc-11.c: Likewise.
* gcc.dg/vect/vect-tail-nomask-1.c: Likewise.
* gcc.dg/vect/vect-reduc-in-order-1.c: Remove dg-do run and use
dg-xfail-run-if instead.
* gcc.dg/vect/vect-reduc-in-order-2.c: Likewise.
* gcc.dg/vect/vect-reduc-in-order-3.c: Likewise.
* gcc.dg/vect/vect-reduc-in-order-4.c: Likewise.
* gcc.dg/vect/vect-reduc-or_1.c: Remove conditional dg-do run.
* gcc.dg/vect/vect-reduc-or_2.c: Likewise.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr79920.c
trunk/gcc/testsuite/gcc.dg/vect/pr80631-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr80631-2.c
trunk/gcc/testsuite/gcc.dg/vect/pr81410.c
trunk/gcc/testsuite/gcc.dg/vect/pr81633.c
trunk/gcc/testsuite/gcc.dg/vect/pr81815.c
trunk/gcc/testsuite/gcc.dg/vect/pr82108.c
trunk/gcc/testsuite/gcc.dg/vect/pr83857.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-10.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-11.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-12.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-11.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-2.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-3.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-4.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-or_1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-or_2.c
trunk/gcc/testsuite/gcc.dg/vect/vect-tail-nomask-1.c
[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535 --- Comment #9 from seurer at gcc dot gnu.org --- Just an FYI that the output of this test case changed a bit somewhere in the range r256987 to r257017: Now it gets this: FAIL: gcc.target/powerpc/pr79439.c scan-assembler-times \\mbl g\\M 1 (found 2 times) previously it failed with this: FAIL: gcc.target/powerpc/pr79439.c scan-assembler-times \\mnop\\M 3 (found 2 times)
[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 --- Comment #6 from Jan Hubicka --- Thanks! -flto makes differnce even for single file benchmarks (because of thrown away type info and extra info from linker). So perhaps that is reason why it did not reproduce?
[Bug target/84010] [sparc64] Problematic TLS code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010 --- Comment #5 from James Clarke --- My patch seems to work for this case: sethi %tie_hi22(tcg_ctx), %g2 ... add %g2, %tie_lo10(tcg_ctx), %g1 ldx [%l7 + %g1], %g1, %tie_ldx(tcg_ctx) stx %g2, [%fp+1783] ! note this is %g2, i.e. just the hi22... callgen_new_label, 0 ldx[%g7+%g1], %i5 ... ldx [%fp+1783], %g1 ! reload the hi22 add %g1, %tie_lo10(tcg_ctx), %i5 ldx [%l7 + %i5], %i5, %tie_ldx(tcg_ctx) ldx [%g7+%i5], %g1 The code gen is something else; I don't understand why it spills the result of the hi22 and re-adds the lo10 (which takes the worst aspects of rematerialisation and spilling), but that's a whole other story.
[Bug fortran/83976] ICE in gfc_add_component_ref, at fortran/class.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83976 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Confirmed. > bailed out with 5/6 Likely configured with --enable-checking=release.
[Bug fortran/84007] ICE with same_type_as with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84007 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from a least 4.8 up to trunk (8.0).
[Bug fortran/84006] [6/7/8 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Known to work||5.5.0 Target Milestone|--- |6.5 Summary|ICE in storage_size() with |[6/7/8 Regression] ICE in |CLASS entity|storage_size() with CLASS ||entity Ever confirmed|0 |1 Known to fail||6.4.0, 7.2.0, 8.0 --- Comment #1 from Dominique d'Humieres --- Confirmed for 6.4.0, 7.2.0 and trunk (8.0), likely r222361. I am not sure the code is valid, it should not lead to an ICE.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #9 from Steve Kargl --- On Wed, Jan 24, 2018 at 10:53:40AM +, guez at lmd dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > --- Comment #8 from Lionel GUEZ --- > It does not seem completely true that gfortran makes no distinction between > qNaN and sNaN. See comment #2.
[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
I think this started with r246301.
This warning s an optimization warning and as the wording says, can have false
positives, the optimizer during path isolation simply finds a basic block
containing a pointer dereference where the pointer is known to be NULL on some
predecessor edge to the BB.
basic_string(basic_string&& __str) noexcept
: _M_dataplus(_M_local_data(), std::move(__str._M_get_allocator()))
{
if (__str._M_is_local())
{
traits_type::copy(_M_local_buf, __str._M_local_buf,
_S_local_capacity + 1);
}
and
template
static _ForwardIterator
__uninit_copy(_InputIterator __first, _InputIterator __last,
_ForwardIterator __result)
{
_ForwardIterator __cur = __result;
__try
{
for (; __first != __last; ++__first, (void)++__cur)
std::_Construct(std::__addressof(*__cur), *__first);
return __cur;
}
are the relevant snippets, the __first != __last guard is what guards the basic
block and the optimizers see some possibility that __first could be NULL in
some case.
[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #5 from Martin Liška --- I can confirm regression from 517 -> 537s of gamess on a zen2 machine with -Ofast -march=native. Let me bisect this one.
[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 --- Comment #4 from Martin Liška --- (In reply to Richard Biener from comment #3) > mgrid also on AMD Fam10: > https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-megrez-head-64/recent.html Interesting about this regression is that mgrid is a single source benchmark. Thus I would not expect a difference in between LTO and non-LTO mode.
[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini --- Mine.
[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed.
[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249 --- Comment #6 from Jason Merrill --- Author: jason Date: Wed Jan 24 15:20:53 2018 New Revision: 257018 URL: https://gcc.gnu.org/viewcvs?rev=257018&root=gcc&view=rev Log: PR c++/82249 - wrong mismatched pack length error. * pt.c (extract_fnparm_pack, tsubst_pack_expansion): Handle unsubstituted function parameter pack. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug fortran/84008] [PDT] ICE accessing kind and len parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84008 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Blocks||82173 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 --- Comment #3 from Richard Biener --- mgrid also on AMD Fam10: https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-megrez-head-64/recent.html
[Bug c++/84026] New: invalid 'unnamed scoped enum is not allowed' when scoped enum has a full qualified-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84026
Bug ID: 84026
Summary: invalid 'unnamed scoped enum is not allowed' when
scoped enum has a full qualified-id
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: smw at gcc dot gnu.org
Target Milestone: ---
On GCC (all versions tested, up to and including 8.0.1 20180117 with -std=c++14
-pedantic) but not o nMSVC, ICC, or clang, the following code
struct S1 {
enum class E1;
};
enum class S1::E1 {}; // OK
struct S2 {
enum class E2;
};
enum class ::S1::E1 {}; // Not OK
spits out the following error.
9 : :9:16: error: unnamed scoped enum is not allowed
enum class ::S1::E1 {}; // Not OK
^~
9 : :9:10: warning: elaborated-type-specifier for a scoped enum must
not use the 'class' keyword
enum class ::S1::E1 {}; // Not OK
^
-
9 : :9:25: error: expected unqualified-id before '{' token
enum class ::S1::E1 {}; // Not OK
^
Looks like it's not quite parsing correctly.
[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Can't reproduce mgrid, facerec and apsi regression on a Haswell machine.
[Bug tree-optimization/84011] Optimize switch table with run-time relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
--- Comment #8 from rguenther at suse dot de ---
On Wed, 24 Jan 2018, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
>
> H.J. Lu changed:
>
>What|Removed |Added
>
> CC||jakub at redhat dot com
> Depends on||36881
>
> --- Comment #6 from H.J. Lu ---
> The code in question is done on purpose:
>
> commit 54af7f7e3f0f38a4cd5667fda9fd9a68ad554df0
> Author: jakub
> Date: Wed Oct 15 06:43:19 2008 +
>
> PR tree-optimization/36881
> * tree-switch-conversion.c (check_final_bb): For flag_pic, check
> that each value doesn't need runtime relocations, for !flag_pic
> check that each value is just a valid initializer constant.
>
> * gcc.dg/tree-ssa/pr36881.c: New test.
>
>
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@141129
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> Should we revisit this decision?
We could add a hook to allow the target to override. Like
targetm.avoid_runtime_relocations_p () or runtime_relocations_expensive_p
() or just (as it seems for SPU) runtime_relocations_supported_p ()?
As said ideally we'd simply avoid creating relocations for string
constants or other constant initializers. Maybe that's even possible
in some weird ways via using section labels/addresses? Thus make
the table contain
.Lstring1 - .section_start_of_where_Lstring1_is,
...
and thus a constant initializer using some extension to query that
section start or even the offset -- __builtin_offset_from_section_start
("foo")?
[Bug c++/83993] [7/8 Regression] ICE: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Created attachment 43232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43232&action=edit
gcc8-pr83993.patch
Untested patch for the 1) part. With this the testcase doesn't ICE anymore,
but
modified testcase like:
extern const int a[];
const int *const b = &a[1];
int
foo ()
{
return b[0];
}
still ICEs, so 2) needs to be resolved too.
[Bug tree-optimization/84011] Optimize switch table with run-time relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Well, we'd need a target hook for these weirdo targets that don't support them at all (spu, anything else?), and for the rest, perhaps we should think of something better. E.g. if not just some elements of the array return null_pointer_node, but all of them, perhaps we could emit in the array content value - array instead of value and then add array to whatever we load from the array.
[Bug target/84011] Optimize switch table with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 H.J. Lu changed: What|Removed |Added CC||jakub at redhat dot com Depends on||36881 --- Comment #6 from H.J. Lu --- The code in question is done on purpose: commit 54af7f7e3f0f38a4cd5667fda9fd9a68ad554df0 Author: jakub Date: Wed Oct 15 06:43:19 2008 + PR tree-optimization/36881 * tree-switch-conversion.c (check_final_bb): For flag_pic, check that each value doesn't need runtime relocations, for !flag_pic check that each value is just a valid initializer constant. * gcc.dg/tree-ssa/pr36881.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@141129 138bc75d-0d04-0410-961f-82ee72b054a4 Should we revisit this decision? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36881 [Bug 36881] [4.4 Regression] Creating runtime relocations for code which does not need it
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #21 from boger at us dot ibm.com --- (In reply to Alexandre Oliva from comment #19) > I was copied, presumably because the problem occurred in var-tracking. > > I've tried to duplicate the problem on gcc112. I bootstrapped the trunk > (without any --with-cpu flag), and then build attachment 43208 [details] > with stage3: > > $ ./gccgo -B./ -I../../libgo/go -I../powerpc64le-unknown-linux-gnu/libgo > -I../powerpc64le-unknown-linux-gnu/libgo/go -O2 -g t.go -mcpu=power8 -c > [success] > > Given this, I conclude that the problem only occurs if the compiler is > bootstrapped --with-cpu=power[89]. This suggests to me that, although the > ICE is triggered in var-tracking, the problem is unlikely to be there: the > compiler is getting miscompiled. I suppose that, by now, you already knew > that ;-) The problem only occurs when configuring --with-cpu=power8 or 9 AND compiling for split stack. If you are on a system where glibc is 2.17 or older then split stack is not enabled and you won't see the failure even with --with-cpu=power8 or 9.
[Bug testsuite/84023] gcc.dg/ipa/inline-8.c fail with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84023
--- Comment #2 from H.J. Lu ---
(In reply to Richard Biener from comment #1)
> I think that's probably spurious:
>
> void
> set ()
> {
> a=nan("");
> }
> ...
> float a = move (1);
> if (!__builtin_constant_p (a))
> __builtin_abort ();
>
>
> given set doesn't bind locally with -fpic we don't inline it and thus
> the result cannot be constant.
>
> -> testsuite issue
>
> A fix is probably to make set static. That change is pre-approved.
It makes no difference. It still aborts with -fpic.
[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Version|unknown |8.0 Target Milestone|--- |8.0 Summary|Spec2000 regression around |[8 Regression] Spec2000 |Jan 14 and Jan 19 2018 |regression around Jan 14 ||and Jan 19 2018 --- Comment #1 from Richard Biener --- mgrid also on IA64: https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-terbium-head-64/recent.html
[Bug target/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83589 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #10 from Tom de Vries --- Patch with test-case committed. Filed PR84025 to work around this JIT bug in a more optimal way in stage1. Marking resolved-fixed.
[Bug target/84025] New: [nvptx] Don't generate branch-around-nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84025 Bug ID: 84025 Summary: [nvptx] Don't generate branch-around-nothing Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- For PR83589 we have a non-invasive but non-minimal workaround for a JIT bug when translating a branch-around-nothing. We want to fix this better in stage1: by not generating branch-around-nothing.
[Bug target/84011] Optimize switch table with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 --- Comment #5 from H.J. Lu --- (In reply to rguent...@suse.de from comment #4) > > The question is why run-time relocations aren't allowed. > > Probably added to save binary space? An optimization would be to I don't think so: text data bss dec hex filename 714 0 0 714 2ca before my change 240 184 0 424 1a8 after my change My change cuts down size by a wide margin. > add an indirection by, say, only recording the constant offset > into an "array of strings" in the table, thus effectively > > "case1\0case2\0..."[CSWITCH[i]] > > which would require only a relocation to access the single string > constant. But it would prohibit cases of string merging within > those strings unless we implement that as well for this optimization. > Note this might be profitable unconditionally, not just with -fpie/pic > as the CSWITCH table would be smaller (dependent on the total > size of the merged string). True, this is independent of PIE/PIC.
[Bug target/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83589 --- Comment #9 from Tom de Vries --- Author: vries Date: Wed Jan 24 13:52:12 2018 New Revision: 257016 URL: https://gcc.gnu.org/viewcvs?rev=257016&root=gcc&view=rev Log: [nvptx, PR83589] Workaround for branch-around-nothing JIT bug 2018-01-24 Tom de Vries PR target/83589 * config/nvptx/nvptx.c (WORKAROUND_PTXJIT_BUG_2): Define to 1. (nvptx_pc_set, nvptx_condjump_label): New function. Copy from jump.c. Add strict parameter. (prevent_branch_around_nothing): Insert dummy insn between branch to label and label with no ptx insn inbetween. * config/nvptx/nvptx.md (define_insn "fake_nop"): New insn. * testsuite/libgomp.oacc-c-c++-common/pr83589.c: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr83589.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/nvptx/nvptx.c trunk/gcc/config/nvptx/nvptx.md trunk/libgomp/ChangeLog
[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Even large unreduced preprocessed testcases are useful, just xz -9e it and hopefully it won't be that huge anymore.
[Bug fortran/2018] Sqrt causes ice in emit_move_insn, at expr.c:2718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2018 --- Comment #3 from Tom de Vries --- Author: vries Date: Wed Jan 24 13:52:12 2018 New Revision: 257016 URL: https://gcc.gnu.org/viewcvs?rev=257016&root=gcc&view=rev Log: [nvptx, PR83589] Workaround for branch-around-nothing JIT bug 2018-01-24 Tom de Vries PR target/83589 * config/nvptx/nvptx.c (WORKAROUND_PTXJIT_BUG_2): Define to 1. (nvptx_pc_set, nvptx_condjump_label): New function. Copy from jump.c. Add strict parameter. (prevent_branch_around_nothing): Insert dummy insn between branch to label and label with no ptx insn inbetween. * config/nvptx/nvptx.md (define_insn "fake_nop"): New insn. * testsuite/libgomp.oacc-c-c++-common/pr83589.c: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr83589.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/nvptx/nvptx.c trunk/gcc/config/nvptx/nvptx.md trunk/libgomp/ChangeLog
[Bug tree-optimization/83992] wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes TestCrashDumpsAllThreads gotools testcase failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992
--- Comment #7 from Jakub Jelinek ---
Corresponding C testcase would be something like:
static inline void
foo (void)
{
int j;
while (1)
for (j = 0; j < 0x7fff; ++j)
;
}
int
main ()
{
foo ();
}
at -O2 -g {,-fno-var-tracking-assignments} {,-gno-statement-frontiers}
[Bug middle-end/84024] [8 Regression] internal compiler error: in operator>, at profile-count.h:855
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84024 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Dup of PR83055 or related to that?
[Bug target/84011] Optimize switch table with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
--- Comment #4 from rguenther at suse dot de ---
On Wed, 24 Jan 2018, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
>
> --- Comment #2 from H.J. Lu ---
> (In reply to Richard Biener from comment #1)
> > Somehow switch-conversion doesn't transform the switch with -f{PIE,PIC}.
> > Without
> > we get
> >
> > phy_modes (phy_interface_t interface)
> > {
> > const char * _1;
> > const char * _4;
> >
> >[local count: 1073741825]:
> > if (interface_2(D) <= 22)
> > goto ; [50.00%]
> > else
> > goto ; [50.00%]
> >
> >[local count: 536870912]:
> > _4 = CSWTCH.0[interface_2(D)];
> >
> >[local count: 1073741825]:
> > # _1 = PHI <_4(3), "unknown"(2)>
> > return _1;
> >
> > due to
> >
> > Bailing out - value from a case would need runtime relocations
> >
> > reloc = initializer_constant_valid_p (val, TREE_TYPE
> > (val));
> > if ((flag_pic && reloc != null_pointer_node)
> > || (!flag_pic && reloc == NULL_TREE))
> > {
> > if (reloc)
> > reason
> > = "value from a case would need runtime
> > relocations";
> > else
> > reason
> > = "value from a case is not a valid initializer";
> > }
> >
> > not sure why we need relocations for string constants?
>
> They do need run-time relocations:
>
> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -fpic -S -o f.s f.i
> [hjl@gnu-skl-1 pr82303]$ cat f.s
> .file "f.i"
> .text
> .section.rodata.str1.1,"aMS",@progbits,1
> .LC0:
> .string "unknown"
> .text
> .p2align 4,,15
> .globl phy_modes
> .type phy_modes, @function
> phy_modes:
> .LFB0:
> .cfi_startproc
> leaq.LC0(%rip), %rax
> cmpl$22, %edi
> ja .L1
> movl%edi, %edi
> leaqCSWTCH.0(%rip), %rax
> movq(%rax,%rdi,8), %rax
> .L1:
> ret
> .cfi_endproc
> .LFE0:
> .size phy_modes, .-phy_modes
> .section.rodata.str1.1
> .LC1:
> .string ""
> .LC2:
> .string "internal"
> .LC3:
> .string "mii"
> .LC4:
> .string "gmii"
> .LC5:
> .string "sgmii"
> .LC6:
> .string "tbi"
> .LC7:
> .string "rev-mii"
> .LC8:
> .string "rmii"
> .LC9:
> .string "rgmii"
> .LC10:
> .string "rgmii-id"
> .LC11:
> .string "rgmii-rxid"
> .LC12:
> .string "rgmii-txid"
> .LC13:
> .string "rtbi"
> .LC14:
> .string "smii"
> .LC15:
> .string "xgmii"
> .LC16:
> .string "moca"
> .LC17:
> .string "qsgmii"
> .LC18:
> .string "trgmii"
> .LC19:
> .string "1000base-x"
> .LC20:
> .string "2500base-x"
> .LC21:
> .string "rxaui"
> .LC22:
> .string "xaui"
> .LC23:
> .string "10gbase-kr"
> .section.data.rel.ro.local,"aw",@progbits
> .align 32
> .type CSWTCH.0, @object
> .size CSWTCH.0, 184
> CSWTCH.0:
> .quad .LC1
> .quad .LC2
> .quad .LC3
> .quad .LC4
> .quad .LC5
> .quad .LC6
> .quad .LC7
> .quad .LC8
> .quad .LC9
> .quad .LC10
> .quad .LC11
> .quad .LC12
> .quad .LC13
> .quad .LC14
> .quad .LC15
> .quad .LC16
> .quad .LC17
> .quad .LC18
> .quad .LC19
> .quad .LC20
> .quad .LC21
> .quad .LC22
> .quad .LC23
> .ident "GCC: (GNU) 8.0.1 20180117 (experimental)"
> .section.note.GNU-stack,"",@progbits
> [hjl@gnu-skl-1 pr82303]$ gcc -c f.s
> [hjl@gnu-skl-1 pr82303]$ readelf -rW f.o
>
> Relocation section '.rela.text' at offset 0x370 contains 2 entries:
> Offset Info Type Symbol's Value
> Symbol's Name + Addend
> 0003 000a0002 R_X86_64_PC32
> .LC0
> - 4
> 0011 00070002 R_X86_64_PC32
> .data.rel.ro.local - 4
>
> Relocation section '.rela.data.rel.ro.local' at offset 0x3a0 contains 23
> entries:
> Offset Info Type Symbol's Value
> Symbol's Name + Addend
> 00050001 R_X86_64_64
> .rodata.str1.1 + 8
> 0008 00050001 R_X86_64_64
> .rodata.str1.1 + 9
> 0010 00050001 R_X86_64_64
> .rodata.str1.1 + 12
> 0018 00050001 R_X86_64_640
[Bug target/84011] Optimize switch table with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
--- Comment #3 from H.J. Lu ---
This patch works on the testcase:
diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
index c2538908340..a1e85407bf3 100644
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -827,16 +827,9 @@ check_final_bb (gswitch *swtch, struct switch_conv_info
*info)
else
{
reloc = initializer_constant_valid_p (val, TREE_TYPE (val));
- if ((flag_pic && reloc != null_pointer_node)
- || (!flag_pic && reloc == NULL_TREE))
- {
- if (reloc)
- reason
- = "value from a case would need runtime relocations";
- else
- reason
- = "value from a case is not a valid initializer";
- }
+ if (reloc == NULL_TREE)
+ reason
+ = "value from a case is not a valid initializer";
}
if (reason)
{
[Bug tree-optimization/83992] wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes TestCrashDumpsAllThreads gotools testcase failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992 --- Comment #6 from Ian Lance Taylor --- In this case the problem happens before the assembler. The bad location information shows up in reemit_insn_block_notes in gcc/final.c. As the first insn in the block has no location, reemit_insn_block_notes adds a NOTE_INSN_BLOCK_BEG note before the second insn. See the NOTE_INSN_BLOCK_BEG in the RTL dump in the initial report. Perhaps reemit_insn_block_notes should check for NOTE_INSN_BASIC_BLOCK as it already checks for NOTE_INSN_BEGIN_STMT. Although the comments for NOTE_INSN_BASIC_BLOCK say that it can not be considered to be reliable at that point.
[Bug target/84011] Optimize switch table with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
--- Comment #2 from H.J. Lu ---
(In reply to Richard Biener from comment #1)
> Somehow switch-conversion doesn't transform the switch with -f{PIE,PIC}.
> Without
> we get
>
> phy_modes (phy_interface_t interface)
> {
> const char * _1;
> const char * _4;
>
>[local count: 1073741825]:
> if (interface_2(D) <= 22)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870912]:
> _4 = CSWTCH.0[interface_2(D)];
>
>[local count: 1073741825]:
> # _1 = PHI <_4(3), "unknown"(2)>
> return _1;
>
> due to
>
> Bailing out - value from a case would need runtime relocations
>
> reloc = initializer_constant_valid_p (val, TREE_TYPE
> (val));
> if ((flag_pic && reloc != null_pointer_node)
> || (!flag_pic && reloc == NULL_TREE))
> {
> if (reloc)
> reason
> = "value from a case would need runtime
> relocations";
> else
> reason
> = "value from a case is not a valid initializer";
> }
>
> not sure why we need relocations for string constants?
They do need run-time relocations:
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -fpic -S -o f.s f.i
[hjl@gnu-skl-1 pr82303]$ cat f.s
.file "f.i"
.text
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "unknown"
.text
.p2align 4,,15
.globl phy_modes
.type phy_modes, @function
phy_modes:
.LFB0:
.cfi_startproc
leaq.LC0(%rip), %rax
cmpl$22, %edi
ja .L1
movl%edi, %edi
leaqCSWTCH.0(%rip), %rax
movq(%rax,%rdi,8), %rax
.L1:
ret
.cfi_endproc
.LFE0:
.size phy_modes, .-phy_modes
.section.rodata.str1.1
.LC1:
.string ""
.LC2:
.string "internal"
.LC3:
.string "mii"
.LC4:
.string "gmii"
.LC5:
.string "sgmii"
.LC6:
.string "tbi"
.LC7:
.string "rev-mii"
.LC8:
.string "rmii"
.LC9:
.string "rgmii"
.LC10:
.string "rgmii-id"
.LC11:
.string "rgmii-rxid"
.LC12:
.string "rgmii-txid"
.LC13:
.string "rtbi"
.LC14:
.string "smii"
.LC15:
.string "xgmii"
.LC16:
.string "moca"
.LC17:
.string "qsgmii"
.LC18:
.string "trgmii"
.LC19:
.string "1000base-x"
.LC20:
.string "2500base-x"
.LC21:
.string "rxaui"
.LC22:
.string "xaui"
.LC23:
.string "10gbase-kr"
.section.data.rel.ro.local,"aw",@progbits
.align 32
.type CSWTCH.0, @object
.size CSWTCH.0, 184
CSWTCH.0:
.quad .LC1
.quad .LC2
.quad .LC3
.quad .LC4
.quad .LC5
.quad .LC6
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad .LC13
.quad .LC14
.quad .LC15
.quad .LC16
.quad .LC17
.quad .LC18
.quad .LC19
.quad .LC20
.quad .LC21
.quad .LC22
.quad .LC23
.ident "GCC: (GNU) 8.0.1 20180117 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-1 pr82303]$ gcc -c f.s
[hjl@gnu-skl-1 pr82303]$ readelf -rW f.o
Relocation section '.rela.text' at offset 0x370 contains 2 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
0003 000a0002 R_X86_64_PC32 .LC0
- 4
0011 00070002 R_X86_64_PC32
.data.rel.ro.local - 4
Relocation section '.rela.data.rel.ro.local' at offset 0x3a0 contains 23
entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
00050001 R_X86_64_64
.rodata.str1.1 + 8
0008 00050001 R_X86_64_64
.rodata.str1.1 + 9
0010 00050001 R_X86_64_64
.rodata.str1.1 + 12
0018 00050001 R_X86_64_64
.rodata.str1.1 + 16
0020 00050001 R_X86_64_64
.rodata.str1.1 + 1b
0028 00050001 R_X86_64_64
.rodata.str1.1 + 21
0030 00050001 R_X86_64_64
.rodata.str1.1 + 25
0038 00050001 R_X86_64_64
.rodata.str1.1 + 2d
0040 00050001 R_X86_64_64
.rodata.str1.1 + 32
[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-24 CC||rguenth at gcc dot gnu.org Version|unknown |7.2.1 Target Milestone|--- |7.3 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Given it fails in mpfr this is maybe a bug in mpfr? What mpfr version are you using?
