[Bug c++/82410] [7/8 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82410
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
CC||gcc-bugs at marehr dot
dialup.fu-b
||erlin.de
--- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I (may) have run into the same issue:
```
template
struct twice
{
value_t _first{};
value_t _second{_first};
struct inner{};
inner get() const
{
return inner{};
}
};
template
twice(value_t first)
-> twice;
int main()
{
auto result = twice{0u}.get();
}
```
[Bug c++/82159] [6/7/8 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82159 --- Comment #9 from chr at terma dot com --- Created attachment 42333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42333&action=edit gcc 7.2.1 20170915 ICE testcase Attached testcase.cpp as file. g++ -O0 testcase.cpp
[Bug c++/82159] [6/7/8 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82159
--- Comment #8 from chr at terma dot com ---
(In reply to Jakub Jelinek from comment #7)
> If you can't provide a testcase, then we can't do anything with it.
> If the inability to provide a testcase is because it contains some
> proprietary stuff that can't be made public, you always have the option to
> reduce the testcase sufficiently that it is small enough to be releasable
> (perhaps after also changing identifiers).
> See https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction for details how
> to do that.
Hello,
I've tried creduce, worked like a charm.
Following test case fails with -O0, but works with -O1-3.
Source file testcase.cpp:
-
class d;
template class g { f e; };
class h : g {
public:
template d operator-(i);
};
class d : public h {
public:
d(const d &);
};
class l : public d {
public:
template l(j);
};
template class m {
public:
typedef typename an::template n ap;
};
template class o { typename m::ap as; };
class D {
public:
l av;
};
template class p : aw {
public:
template p(ay p1, az q) : aw(p1, q) {}
D *ba;
virtual void b() { aw::bc(ba); }
};
template class bj;
template class bm {
public:
typedef int bi;
class bn {};
template class bp {
public:
l bq;
bp(bi, bo q) : bq(q.av - 0) {}
};
bm(bi, bn);
};
template class r;
template
class r>> : public bm>::bn {};
class s : public bm> {
class t {
public:
t(bm *, int);
void bc(D *p1) {
bi a;
bp(a, *p1);
}
};
public:
template s(ay p1, az q) : bm(p1, q) {}
int cb;
virtual int c() { p(this, cb); }
};
template class H {
r>> cf;
virtual s cg() { s(0, cf); }
};
template class ci> class I {
public:
I() { ci(); }
};
class u {
public:
template class n : I {};
};
void v() { o k; }
int main() {
return 0;
}
Steps to Repro:
-
g++ -O0 testcase.cpp
testcase.cpp: In constructor ‘bm< >::bp::bp(bm<
>::bi, bo) [with bo = D; =
bj<2, double>]’:
testcase.cpp:38:31: internal compiler error: in assign_temp, at function.c:968
bp(bi, bo q) : bq(q.av - 0) {}
^
Compiler used:
-
The one included in Fedora 26 gcc version 7.2.1 20170915 (Red Hat 7.2.1-2)
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)
[Bug target/82499] New: x86: small stack initial adjustments could use push
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82499
Bug ID: 82499
Summary: x86: small stack initial adjustments could use push
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: benjamin at benjamin dot pe
Target Milestone: ---
consider:
extern void g(void);
int f() {
g();
return 42;
}
For f, gcc -Os on the trunk generates
subq $8, %rsp
call g
movl $42, %eax
popq %rdx
ret
clang 5.0.0 cleverly generates:
pushq %rax
callq g
movl $42, %eax
popq %rcx
retq
"pushq %rax" ends up being 2 bytes shorter than "subq $8, %rsp".
[Bug target/82498] New: Missed optimization for x86 rotate instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498
Bug ID: 82498
Summary: Missed optimization for x86 rotate instruction
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
GCC doesn't seem to realize that x86 masks the high bits in the rol/ror
instructions. GCC 7.2.0 on x86-64 compiles this function, which is attempting
to do a 32-bit rotate without invoking undefined behavior
#include
uint32_t rotate_left(uint32_t input, uint8_t rot)
{
if(rot == 0)
return input;
rot %= 8 * sizeof(uint32_t);
return static_cast((input << rot) | (input >>
(8*sizeof(uint32_t)-rot)));;
}
Into
movl%esi, %ecx # rot, rot
movl%edi, %eax # input, tmp97
andl$31, %ecx #, rot
roll%cl, %eax # rot, tmp97
testb %sil, %sil # rot
cmove %edi, %eax # tmp97,, input,
The `andl` is unnecessary as the machine will mask the rotation amount for us.
In addition the testb/cmov pair can be omitted. Overall this resulted in a ~15%
slowdown in some code using many variable rotations (CAST-128 cipher being used
in an OpenPGP library).
Some related (but not quite the same, and supposedly fixed) issues: 57157 59100
[Bug libstdc++/82417] Macros from defined in C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82417 --- Comment #4 from Jonathan Wakely --- I'm not opposed to a warning in principle, but I'd prefer it to be one controllable by a -Wxxx option. I don't know how to do that using the preprocessor, so we'd have to do something like: #ifndef _GLIBCXX_NO_CCOMPLEX_WARNING # warning "Including makes no sense. Define _GLIBCXX_NO_CCOMPLEX_WARNING to disable this warning." #endif And that is a bit ugly.
[Bug libstdc++/82496] Optimization breaks duration_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82496 --- Comment #4 from Jeff Benshetler --- My apologies. Adding -Wall shows: warning: no return statement in function returning non-void [-Wreturn-type]
[Bug libstdc++/82496] Optimization breaks duration_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82496
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Jonathan Wakely ---
Your asSeconds doesn't return anything:
float asSeconds(Duration dur) {
using WantedDuration = duration;
auto f_secs = duration_cast(dur);
}
dc.cc: In function ‘float asSeconds(Duration)’:
dc.cc:19:1: warning: no return statement in function returning non-void
[-Wreturn-type]
}
^
[Bug libstdc++/82496] Optimization breaks duration_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82496 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-09 Component|c++ |libstdc++ Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/82496] Optimization breaks duration_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82496 --- Comment #2 from Jeff Benshetler --- I confirmed that the identical problem exists on Linux for both gcc-6.4.0 and gcc-7.2.0.
[Bug fortran/82497] New: valgrind error in get_pdt_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82497 Bug ID: 82497 Summary: valgrind error in get_pdt_constructor Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I did a build of gcc trunk revision 253416 fortran compiler. For the fortran source code file gcc/testsuite/gfortran.dg/pdt_14.f03 I get the following results: $ ~/gcc/results.253416.valgrind/bin/gfortran -c ./gfortran.dg/pdt_14.f03 ==11157== Invalid read of size 4 ==11157==at 0x73E336: get_pdt_constructor(gfc_expr*, gfc_constructor**, gfc_symbol*) (resolve.c:1191) ==11157==by 0x74CDBC: resolve_structure_cons(gfc_expr*, int) (resolve.c:1246) ==11157==by 0x754741: resolve_values(gfc_symbol*) (resolve.c:11386) ==11157==by 0x768382: do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4061) The bug seems to appear between revisions 251689 and 252962.
[Bug c++/82496] Optimization breaks duration_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82496 Jeff Benshetler changed: What|Removed |Added CC||jeff.benshetler at stackpath dot c ||om --- Comment #1 from Jeff Benshetler --- Created attachment 42332 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42332&action=edit Preprocessed file that triggers the bug. When compiled without optimization and run, running the executable produces the following correct output: deltaT=2.00275 When compiled with any level of optimization (-O1 or greater), running the executable produces the following erroneous output: deltaT=0
[Bug c++/82496] New: Optimization breaks duration_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82496 Bug ID: 82496 Summary: Optimization breaks duration_cast Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeff.benshetler at stackpath dot com Target Milestone: --- Created attachment 42331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42331&action=edit Compiler output duration_cast always returns zero when using any level of optimization. duration_cast works properly when compiled without optimization GCC Version: g++ (GCC) 6.3.0 System Type: Darwin Jeffs-MacBook-Pro.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64 Options when GCC was configured/built: /Users/jbenshetler/build/gcc/objdir/../gcc-6.3.0/configure --prefix=/opt/gcc-6.3.0 --enable-languages=c,c++,fortran --disable-multilib Exact command line passed to gcc triggering the bug: g++ -O1 -o duration_cast_error -v -save-temps duration_cast_error.cpp 2> duration_cast_error.log
[Bug gcov-profile/82457] libgcov fork and exec hooks not always used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82457 --- Comment #7 from Mikhail Maltsev --- I meant libgcov
[Bug target/71648] C++ ICE on ppc64 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648 Konstantinos Margaritis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Konstantinos Margaritis --- verified in both g++ 6 and 7.
[Bug target/82445] ARM target generates unaligned STRD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82445 Richard Earnshaw changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org
[Bug fortran/82471] Reorder loop for unfavorable index ordering in DO CONCURRENT and FORALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW Summary|do-concurrent is much |Reorder loop for |slower than ordinary-do!|unfavorable index ordering ||in DO CONCURRENT and ||FORALL Severity|normal |enhancement --- Comment #7 from Thomas Koenig --- Confirming as an enhancement request. The workaround is clear, see comment #1.
[Bug fortran/82471] do-concurrent is much slower than ordinary-do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #6 from Thomas Koenig --- *** Bug 82495 has been marked as a duplicate of this bug. ***
[Bug fortran/82495] forall is very slow comparing to other compilers!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82495 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Thomas Koenig --- Same root cause as PR 82471 - loop interchange (or lack thereof). *** This bug has been marked as a duplicate of bug 82471 ***
[Bug gcov-profile/82457] libgcov fork and exec hooks not always used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82457 --- Comment #6 from Mikhail Maltsev --- (In reply to Andrew Pinski from comment #5) > Well fork and exec does not need to be the semantics of POSIX says it it. > So warning is not a good idea. But don't libgcc wrappers already rely on those semantics?
[Bug target/82447] [IVOPTS] Consider removing cmp instruction while iterating on an array of known bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82447 --- Comment #7 from amker at gcc dot gnu.org --- So with necessary IV candidates added, current cost computation has tie between address candidate and counting down candidate. The tie is introduced because counting down candidate requires invariant expression (thus increased cost by 1); and it is preferred in determine_group_iv_cost_cond (by decreasing cost by 1). From experience, penalizing invariant expressions in address type IV_USE is generally better in large cases. we may be able to break tie with below trivial change: /* When the condition is a comparison of the candidate IV against zero, prefer this IV. TODO: The constant that we're subtracting from the cost should be target-dependent. This information should be added to the target costs for each backend. */ if (!elim_cost.infinite_cost_p () /* Do not try to decrease infinite! */ && integer_zerop (*bound_cst) && (operand_equal_p (*control_var, cand->var_after, 0) || operand_equal_p (*control_var, cand->var_before, 0))) -elim_cost -= 1; +elim_cost -= 2; It breaks the tie while doesn't change behavior in large case which has multiple address type IV_USEs so preference of counting down IV cand can be cancelled.
[Bug fortran/82495] New: forall is very slow comparing to other compilers!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82495 Bug ID: 82495 Summary: forall is very slow comparing to other compilers! Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- This forall construct is very slow comparing to other compilers: PROGRAM FORALL_EXECUTION IMPLICIT NONE REAL, ALLOCATABLE :: A(:,:,:), B(:,:,:), C(:,:,:) INTEGER :: I, J, K REAL :: TIC INTEGER :: START, FINISH1, FINISH2, FINISH3, FINISH4, FINISH5, FINISH6 INTEGER, PARAMETER :: L = 1024, M = 512, N = 512 ALLOCATE(A(L,M,N), B(L,M,N), C(L,M,N) ) CALL RANDOM_NUMBER(A) CALL RANDOM_NUMBER(B) CALL RANDOM_NUMBER(C) CALL SYSTEM_CLOCK(START, TIC) FORALL(I=1:L, J=1:M, K=1:N) C(I,J,K) = A(I,J,K) + B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH1) PRINT*,'I,J,K ',(FINISH1-START)/TIC FORALL(I=1:L, K=1:N, J=1:M) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH2) PRINT*,'I,K,J ',(FINISH2-FINISH1)/TIC FORALL(J=1:M, I=1:L, K=1:N) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH3) PRINT*,'J,I,K ',(FINISH3-FINISH2)/TIC FORALL(J=1:M, K=1:N, I=1:L) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH4) PRINT*,'J,K,I ',(FINISH4-FINISH3)/TIC FORALL(K=1:N, I=1:L, J=1:M) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH5) PRINT*,'K,I,J ',(FINISH5-FINISH4)/TIC FORALL(K=1:N, J=1:M, I=1:L) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH6) PRINT*,'K,J,I ',(FINISH6-FINISH5)/TIC END PROGRAM This program gives: MinGW 7.2.0 : -Ofast I,J,K 0.45309 I,K,J 0.53118 J,I,K9.34400082 J,K,I14.0630007 K,I,J24.0460014 K,J,I25.9690018 Ubuntu 7.2.0 : -Ofast I,J,K 0.45426 I,K,J 0.44115 J,I,K9.14200020 J,K,I13.2140007 K,I,J22.3860016 K,J,I24.7680016 But with other compilers: PGI Fortran 17.04 : -fast I,J,K0.5161750 I,K,J0.3963450 J,I,K0.2786350 J,K,I0.3162010 K,I,J0.3141180 K,J,I0.2789040 Flang : -Ofast I,J,K0.4740010 I,K,J0.2965370 J,I,K0.3045340 J,K,I0.4017220 K,I,J0.2853640 K,J,I0.3081510 Intel Fortran 18.0 : -fast I,J,K 0.437 I,K,J 0.391 J,I,K 0.281 J,K,I 0.360 K,I,J 0.328 K,J,I 0.281 I think this bug is independent of do-concurrent!
[Bug target/82464] s390x z14: vector float: invalid parameter combination for intrinsic '__builtin_s390_vec_xor'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464 --- Comment #4 from Konstantinos Margaritis --- Fix confirmed to work.
[Bug target/82465] vec_sqrt() for vector double erroneously fails for z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82465 --- Comment #2 from Konstantinos Margaritis --- Fix confirmed to work.
[Bug target/82447] [IVOPTS] Consider removing cmp instruction while iterating on an array of known bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82447 --- Comment #6 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > (In reply to amker from comment #4) > > (In reply to Jakub Jelinek from comment #2) > > > Indeed. But when the body is: > > > sum += a[size - 1 - i]; > > > while base 128U with step -1U is considered, it isn't found as the > > > cheapest > > > for some reason either. > > > > On 64-bit targets, candidate [128, -1] is added in unsigned int type, while > > address IV has pointer type. IVOPTs simply skips the candidate because it > > has smaller precision than the IV use. > > Yeah, but can't we also add [128UL, -1UL] candidate if we see there are IVs > of that bitsize? Conversion from that to the unsigned int IV is cheap. Yes we can. For constant niters loop, currently it's ivcanon adding the counting down IV, I mentioned during cauldron that we may want to get rid of iv_canonicalization by adding all necessary IV candidates in IVOTPs.
[Bug target/82447] [IVOPTS] Consider removing cmp instruction while iterating on an array of known bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82447 --- Comment #5 from Jakub Jelinek --- (In reply to amker from comment #4) > (In reply to Jakub Jelinek from comment #2) > > Indeed. But when the body is: > > sum += a[size - 1 - i]; > > while base 128U with step -1U is considered, it isn't found as the cheapest > > for some reason either. > > On 64-bit targets, candidate [128, -1] is added in unsigned int type, while > address IV has pointer type. IVOPTs simply skips the candidate because it > has smaller precision than the IV use. Yeah, but can't we also add [128UL, -1UL] candidate if we see there are IVs of that bitsize? Conversion from that to the unsigned int IV is cheap.
[Bug target/82447] [IVOPTS] Consider removing cmp instruction while iterating on an array of known bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82447 --- Comment #4 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) > Indeed. But when the body is: > sum += a[size - 1 - i]; > while base 128U with step -1U is considered, it isn't found as the cheapest > for some reason either. On 64-bit targets, candidate [128, -1] is added in unsigned int type, while address IV has pointer type. IVOPTs simply skips the candidate because it has smaller precision than the IV use. On 32-bit targets, I increased cost in case of invariant expression on purpose in order to avoid generating too many invariant expressions. So I think this strategy works better for large cases but not for the simplest cases. Probably we should special case simple case with only one address type IV.
[Bug target/82447] [IVOPTS] Consider removing cmp instruction while iterating on an array of known bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82447 --- Comment #3 from amker at gcc dot gnu.org --- BTW, which target is this? Thanks.
[Bug tree-optimization/82397] [8 Regression] qsort comparator non-negative on sorted output: 1 in vect_analyze_data_ref_accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397 --- Comment #11 from Richard Biener --- Author: rguenth Date: Mon Oct 9 14:13:43 2017 New Revision: 253547 URL: https://gcc.gnu.org/viewcvs?rev=253547&root=gcc&view=rev Log: 2017-10-09 Richard Biener PR tree-optimization/82397 * tree-data-ref.c (data_ref_compare_tree): Make sure to return equality only for semantically equal trees. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c
[Bug tree-optimization/82492] [6/7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Richard Biener --- Dup of PR82264. *** This bug has been marked as a duplicate of bug 82264 ***
[Bug tree-optimization/82264] [6 Regression] ICE in vn_phi_lookup at gcc/tree-ssa-sccvn.c:3125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82264 Richard Biener changed: What|Removed |Added CC||gcc at lanrules dot de --- Comment #5 from Richard Biener --- *** Bug 82492 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/82492] [6/7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Status|NEW |ASSIGNED Target Milestone|--- |6.5 --- Comment #6 from Richard Biener --- Mine.
[Bug tree-optimization/82449] code-gen error in get_rename_from_scev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82449 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 82449, which changed state. Bug 82449 Summary: code-gen error in get_rename_from_scev https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82449 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/82449] code-gen error in get_rename_from_scev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82449 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Oct 9 13:50:10 2017 New Revision: 253546 URL: https://gcc.gnu.org/viewcvs?rev=253546&root=gcc&view=rev Log: 2017-10-09 Richard Biener PR tree-optimization/82449 * sese.c (scev_analyzable_p): Check whether the SCEV is linear. * tree-chrec.h (evolution_function_is_constant_p): Adjust to allow constant addresses. * tree-chrec.c (scev_is_linear_expression): Constant evolutions are linear. * gfortran.dg/graphite/pr82449.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/graphite/pr82449.f Modified: trunk/gcc/ChangeLog trunk/gcc/sese.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-chrec.h
[Bug lto/81351] [8 regression] Many LTO testcases FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81351 Renlin Li changed: What|Removed |Added CC||renlin at gcc dot gnu.org --- Comment #5 from Renlin Li --- similar failures happens on aarch64-linux-gnu & arm-linux-gnueabihf
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #12 from Christophe Lyon --- There are several differences, but I'm not fluent in fortran. In case of doubt, note that 'armeb' means arm target in big-endian mode.
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #11 from Christophe Lyon --- Created attachment 42330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42330&action=edit tree dump for armeb This is the tree-dump-original for the testcase of comment #8. My compiler is configured with: --target=armeb-none-linux-gnueabihf --with-float=hard --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16
[Bug middle-end/81832] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81832 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||amker at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from amker at gcc dot gnu.org --- fixed.
[Bug tree-optimization/82163] [8 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82163 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from amker at gcc dot gnu.org --- Fixed.
[Bug target/82442] vect/pr31699.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82442 Vidya Praveen changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-09 Ever confirmed|0 |1
[Bug tree-optimization/82492] [6/7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492 --- Comment #5 from Markus Trippelsdorf --- 0xad530f crash_signal ../../gcc-7.2.0/gcc/toplev.c:337 0xc2bbd8 gcond* dyn_cast(gimple*) ../../gcc-7.2.0/gcc/is-a.h:219 0xc2bbd8 vn_phi_lookup ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:3087 0xc2bbd8 visit_phi ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:3882 0xc2bbd8 visit_use ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:3948 0xc2c870 process_scc ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:4296 0xc2c870 extract_and_process_scc_for_name ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:4352 0xc2c870 DFS ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:4404 0xc2d766 sccvn_dom_walker::before_dom_children(basic_block_def*) ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:4857 0x10beb0a dom_walker::walk(basic_block_def*) ../../gcc-7.2.0/gcc/domwalk.c:265 0xc2e32a run_scc_vn(vn_lookup_kind) ../../gcc-7.2.0/gcc/tree-ssa-sccvn.c:4981 0xc03744 execute ../../gcc-7.2.0/gcc/tree-ssa-pre.c:5201
[Bug tree-optimization/82492] [6/7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492 Markus Trippelsdorf changed: What|Removed |Added Priority|P3 |P1 Known to work||6.3.1, 7.1.1 Summary|[7 Regression] ICE: |[6/7 Regression] ICE: |Segmentation fault |Segmentation fault Known to fail||6.4.1 --- Comment #4 from Markus Trippelsdorf --- 6.3.1 and 7.1.1 work fine. So two branch regressions.
[Bug tree-optimization/82492] [7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492
Markus Trippelsdorf changed:
What|Removed |Added
Component|c++ |tree-optimization
--- Comment #3 from Markus Trippelsdorf ---
Segfaults in tree-ssa-sccvn:
trippels@gcc67 ~ % cat _png.ii
void _setjmp(int);
void png_set_longjmp_fn();
struct SeqBase {
virtual void m_fn1() {}
void m_fn2() { m_fn1(); }
} a;
void write_png() {
a.m_fn2();
try {
png_set_longjmp_fn();
_setjmp(0);
} catch (...) {
}
}
trippels@gcc67 ~ % ~/gcc_7/usr/local/bin/g++ -c -O2 _png.ii
_png.ii: In function ‘void write_png()’:
_png.ii:7:6: internal compiler error: Segmentation fault
void write_png() {
^
#0 0x013474d1 in visit_use(tree_node*) ()
#1 0x01345a55 in DFS(tree_node*) ()
#2 0x01344630 in
sccvn_dom_walker::before_dom_children(basic_block_def*) ()
#3 0x014a8835 in dom_walker::walk(basic_block_def*) ()
#4 0x01342a98 in run_scc_vn(vn_lookup_kind) ()
#5 0x01329537 in (anonymous namespace)::pass_fre::execute(function*)
()
#6 0x0120e434 in execute_one_pass(opt_pass*) ()
#7 0x00893ed2 in execute_pass_list(function*, opt_pass*) [clone
.cold.77] ()
#8 0x01556441 in symbol_table::compile() ()
#9 0x010b3aff in symbol_table::finalize_compilation_unit() ()
#10 0x0159b4b0 in compile_file() ()
#11 0x00f6130d in toplev::main(int, char**) ()
#12 0x00f625ab in main ()
[Bug c++/82357] [8 Regression] bogus error: cannot bind bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82357
--- Comment #4 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #3)
> trippels@gcc67 ~ % cat _png.ii
> void _setjmp(int);
> void png_set_longjmp_fn();
> struct SeqBase {
> virtual void m_fn1() {}
> void m_fn2() { m_fn1(); }
> } a;
> void write_png() {
> a.m_fn2();
> try {
> png_set_longjmp_fn();
> _setjmp(0);
> } catch (...) {
> }
> }
> trippels@gcc67 ~ % ~/gcc_7/usr/local/bin/g++ -c -O2 _png.ii
> _png.ii: In function ‘void write_png()’:
> _png.ii:7:6: internal compiler error: Segmentation fault
> void write_png() {
> ^
>
> #0 0x013474d1 in visit_use(tree_node*) ()
> #1 0x01345a55 in DFS(tree_node*) ()
> #2 0x01344630 in
> sccvn_dom_walker::before_dom_children(basic_block_def*) ()
> #3 0x014a8835 in dom_walker::walk(basic_block_def*) ()
> #4 0x01342a98 in run_scc_vn(vn_lookup_kind) ()
> #5 0x01329537 in (anonymous
> namespace)::pass_fre::execute(function*) ()
> #6 0x0120e434 in execute_one_pass(opt_pass*) ()
> #7 0x00893ed2 in execute_pass_list(function*, opt_pass*) [clone
> .cold.77] ()
> #8 0x01556441 in symbol_table::compile() ()
> #9 0x010b3aff in symbol_table::finalize_compilation_unit() ()
> #10 0x0159b4b0 in compile_file() ()
> #11 0x00f6130d in toplev::main(int, char**) ()
> #12 0x00f625ab in main ()
Sorry wrong PR. Please ignore.
[Bug c++/82357] [8 Regression] bogus error: cannot bind bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82357
--- Comment #3 from Markus Trippelsdorf ---
trippels@gcc67 ~ % cat _png.ii
void _setjmp(int);
void png_set_longjmp_fn();
struct SeqBase {
virtual void m_fn1() {}
void m_fn2() { m_fn1(); }
} a;
void write_png() {
a.m_fn2();
try {
png_set_longjmp_fn();
_setjmp(0);
} catch (...) {
}
}
trippels@gcc67 ~ % ~/gcc_7/usr/local/bin/g++ -c -O2 _png.ii
_png.ii: In function ‘void write_png()’:
_png.ii:7:6: internal compiler error: Segmentation fault
void write_png() {
^
#0 0x013474d1 in visit_use(tree_node*) ()
#1 0x01345a55 in DFS(tree_node*) ()
#2 0x01344630 in
sccvn_dom_walker::before_dom_children(basic_block_def*) ()
#3 0x014a8835 in dom_walker::walk(basic_block_def*) ()
#4 0x01342a98 in run_scc_vn(vn_lookup_kind) ()
#5 0x01329537 in (anonymous namespace)::pass_fre::execute(function*)
()
#6 0x0120e434 in execute_one_pass(opt_pass*) ()
#7 0x00893ed2 in execute_pass_list(function*, opt_pass*) [clone
.cold.77] ()
#8 0x01556441 in symbol_table::compile() ()
#9 0x010b3aff in symbol_table::finalize_compilation_unit() ()
#10 0x0159b4b0 in compile_file() ()
#11 0x00f6130d in toplev::main(int, char**) ()
#12 0x00f625ab in main ()
[Bug c++/82357] [8 Regression] bogus error: cannot bind bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82357 Markus Trippelsdorf changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from Markus Trippelsdorf --- Also seen when building Chromium: ../../v8/src/parsing/expression-classifier.h: In member function ‘void v8::internal::ExpressionClassifier::Accumulate(v8::internal::ExpressionClassifier*, unsigned int, bool)’: ../../v8/src/parsing/expression-classifier.h:321:40: error: cannot bind bitfield ‘((v8::internal::ExpressionClassifier*)this)->v8::internal::ExpressionClassifier::function_properties_’ to ‘unsigned int&’ function_properties_ |= inner->function_properties_; ^~~~ ../../v8/src/parsing/expression-classifier.h:330:33: error: cannot bind bitfield ‘((v8::internal::ExpressionClassifier*)this)->v8::internal::ExpressionClassifier::invalid_productions_’ to ‘unsigned int&’ invalid_productions_ |= errors; ^~
[Bug tree-optimization/82491] UBSAN in gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82491
--- Comment #1 from Richard Biener ---
if (!integer_zerop (TREE_OPERAND (base, 1)))
{
if (!tree_fits_shwi_p (TREE_OPERAND (base, 1)))
return NULL_TREE;
the above check isn't enough to catch overflow below.
*bit_offset += (mem_ref_offset (base).to_short_addr ()
* BITS_PER_UNIT);
I suppose doing
offset_int boff = *bit_offset + mem_ref_offset (base) * BITS_PER_UNIT;
if (boff.fits_shwi_p ())
*bit_offset = boff.to_short_addr ();
else
return NULL_TREE;
would work.
[Bug c++/82492] [7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-09 CC||trippels at gcc dot gnu.org Known to work||8.0 Summary|ICE Segmentation fault |[7 Regression] ICE: ||Segmentation fault Ever confirmed|0 |1 Known to fail||7.2.1 --- Comment #2 from Markus Trippelsdorf --- Confirmed. Reducing...
[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82494 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-09 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think there's a dup somewhere. We've discussed that typedef int *lambda_vector; is simply too optimistic. The machinery assumes this is an arbitrary precision integer ;) A optimistic "fix" would be to make it int64_t, probably catching most (if not all) practical cases (all overflows are possibly wrong-code!). A real fix would involve either using gmp (ugh) or making a lot of routines failable that are not right now plus using overflow-detecting math (and fail).
[Bug target/82463] vec_madd does not map to __builtin_s390_vfmasb for z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82463 --- Comment #2 from Andreas Krebbel --- Author: krebbel Date: Mon Oct 9 12:07:54 2017 New Revision: 253543 URL: https://gcc.gnu.org/viewcvs?rev=253543&root=gcc&view=rev Log: S/390: PR82463: Fix vec_madd header file definition The builtin was not correctly defined in the vecintrin.h header file. gcc/testsuite/ChangeLog: 2017-10-09 Andreas Krebbel PR target/82463 * gcc.target/s390/zvector/pr82463.c: New test. gcc/ChangeLog: 2017-10-09 Andreas Krebbel PR target/82463 * config/s390/vecintrin.h (vec_madd, vec_msub): Fix macro definitions. Added: trunk/gcc/testsuite/gcc.target/s390/zvector/pr82463.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/vecintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/82465] vec_sqrt() for vector double erroneously fails for z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82465 --- Comment #1 from Andreas Krebbel --- Author: krebbel Date: Mon Oct 9 12:06:11 2017 New Revision: 253542 URL: https://gcc.gnu.org/viewcvs?rev=253542&root=gcc&view=rev Log: S/390: PR82465: Fix vec_sqrt builtin flags The vector double variant is available with z13. A wrong flag in the s390-builtins.def file triggered an error when compiling for z13. gcc/testsuite/ChangeLog: 2017-10-09 Andreas Krebbel PR target/82465 * gcc.target/s390/zvector/pr82465.c: New test. gcc/ChangeLog: 2017-10-09 Andreas Krebbel PR target/82465 * config/s390/s390-builtins.def (vec_sqrt): Fix builtin flags. Added: trunk/gcc/testsuite/gcc.target/s390/zvector/pr82465.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390-builtins.def trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/82454] Possible future performance regression in x86 for 64-bit constant expansions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82454 --- Comment #3 from Richard Biener --- Note the missed-optimization is that any (1 << C) >> x can be instead written as 1 << C - x iff we know that C - x > 0. For C == precision(x)-1 we can infer that directly from x being mentioned in the shift.
[Bug rtl-optimization/82454] Possible future performance regression in x86 for 64-bit constant expansions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82454
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-10-09
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
__INT64_TYPE__ f1 (__INT64_TYPE__ i)
{
return (((__INT64_TYPE__)1) << 63) >> i;
}
is already an existing missed optimization.
[Bug tree-optimization/82494] New: UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82494 Bug ID: 82494 Summary: UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- With bootstrap-ubsan I see: $ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. /home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/torture/pr60183.c -c -O3 ../../gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int' #0 0x3a3b770 in lambda_matrix_right_hermite ../../gcc/tree-data-ref.c:3427 #1 0x3a3c1e3 in analyze_subscript_affine_affine ../../gcc/tree-data-ref.c:3546 #2 0x3a3e406 in analyze_siv_subscript ../../gcc/tree-data-ref.c:3794 #3 0x3a3f8df in analyze_overlapping_iterations ../../gcc/tree-data-ref.c:4041 #4 0x3a42e7e in subscript_dependence_tester_1 ../../gcc/tree-data-ref.c:4582 #5 0x3a43214 in subscript_dependence_tester ../../gcc/tree-data-ref.c:4632 #6 0x3a4361a in compute_affine_dependence(data_dependence_relation*, loop*) ../../gcc/tree-data-ref.c:4691 #7 0x3a43b25 in compute_all_dependences(vec, vec*, vec, bool) ../../gcc/tree-data-ref.c:4758 #8 0x3a456c7 in compute_data_dependences_for_loop(loop*, bool, vec*, vec*, vec*) ../../gcc/tree-data-ref.c:5156 #9 0x1f8bc55 in tree_predictive_commoning_loop ../../gcc/tree-predcom.c:3050 #10 0x1f8c1c2 in tree_predictive_commoning() ../../gcc/tree-predcom.c:3172 #11 0x1f8c242 in run_tree_predictive_commoning ../../gcc/tree-predcom.c:3197 #12 0x1f8c38d in execute ../../gcc/tree-predcom.c:3226 #13 0x18f223a in execute_one_pass(opt_pass*) ../../gcc/passes.c:2495 #14 0x18f2bcb in execute_pass_list_1 ../../gcc/passes.c:2584 #15 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #16 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #17 0x18f2d1f in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2595 #18 0xd34522 in cgraph_node::expand() ../../gcc/cgraphunit.c:2115 #19 0xd35b07 in expand_all_functions ../../gcc/cgraphunit.c:2251 #20 0xd38201 in symbol_table::compile() ../../gcc/cgraphunit.c:2599 #21 0xd38958 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2692 #22 0x1cdc527 in compile_file ../../gcc/toplev.c:481 #23 0x1ce2c84 in do_compile ../../gcc/toplev.c:2037 #24 0x1ce32b3 in toplev::main(int, char**) ../../gcc/toplev.c:2172 #25 0x3aaf9e0 in main ../../gcc/main.c:39 #26 0x14a79f7caf49 in __libc_start_main (/lib64/libc.so.6+0x20f49) #27 0x7d93b9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x7d93b9) ../../gcc/tree-data-ref.c:3350:16: runtime error: signed integer overflow: 1073741824 + 1073741824 cannot be represented in type 'int' #0 0x3a3af5f in lambda_matrix_row_add ../../gcc/tree-data-ref.c:3350 #1 0x3a3b890 in lambda_matrix_right_hermite ../../gcc/tree-data-ref.c:3432 #2 0x3a3c1e3 in analyze_subscript_affine_affine ../../gcc/tree-data-ref.c:3546 #3 0x3a3e406 in analyze_siv_subscript ../../gcc/tree-data-ref.c:3794 #4 0x3a3f8df in analyze_overlapping_iterations ../../gcc/tree-data-ref.c:4041 #5 0x3a42e7e in subscript_dependence_tester_1 ../../gcc/tree-data-ref.c:4582 #6 0x3a43214 in subscript_dependence_tester ../../gcc/tree-data-ref.c:4632 #7 0x3a4361a in compute_affine_dependence(data_dependence_relation*, loop*) ../../gcc/tree-data-ref.c:4691 #8 0x3a43b25 in compute_all_dependences(vec, vec*, vec, bool) ../../gcc/tree-data-ref.c:4758 #9 0x3a456c7 in compute_data_dependences_for_loop(loop*, bool, vec*, vec*, vec*) ../../gcc/tree-data-ref.c:5156 #10 0x1f8bc55 in tree_predictive_commoning_loop ../../gcc/tree-predcom.c:3050 #11 0x1f8c1c2 in tree_predictive_commoning() ../../gcc/tree-predcom.c:3172 #12 0x1f8c242 in run_tree_predictive_commoning ../../gcc/tree-predcom.c:3197 #13 0x1f8c38d in execute ../../gcc/tree-predcom.c:3226 #14 0x18f223a in execute_one_pass(opt_pass*) ../../gcc/passes.c:2495 #15 0x18f2bcb in execute_pass_list_1 ../../gcc/passes.c:2584 #16 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #17 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #18 0x18f2d1f in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2595 #19 0xd34522 in cgraph_node::expand() ../../gcc/cgraphunit.c:2115 #20 0xd35b07 in expand_all_functions ../../gcc/cgraphunit.c:2251 #21 0xd38201 in symbol_table::compile() ../../gcc/cgraphunit.c:2599 #22 0xd38958 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2692 #
[Bug c/82492] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492 --- Comment #1 from gcc at lanrules dot de --- Created attachment 42329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42329&action=edit preprocessed file
[Bug tree-optimization/82493] New: UBSAN in gcc/sbitmap.c:368:28: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82493 Bug ID: 82493 Summary: UBSAN in gcc/sbitmap.c:368:28: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: law at gcc dot gnu.org Target Milestone: --- With bootstrap-ubsan I see: UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. /home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/vect/pr79920.c -O3 -fno-vect-cost-model ../../gcc/sbitmap.c:368:28: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' #0 0x3b424ba in bitmap_bit_in_range_p(simple_bitmap_def const*, unsigned int, unsigned int) ../../gcc/sbitmap.c:368 #1 0x20a3533 in live_bytes_read ../../gcc/tree-ssa-dse.c:496 #2 0x20a390f in dse_classify_store ../../gcc/tree-ssa-dse.c:594 #3 0x20a45e7 in dse_dom_walker::dse_optimize_stmt(gimple_stmt_iterator*) ../../gcc/tree-ssa-dse.c:820 #4 0x20a47d1 in dse_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-dse.c:852 #5 0x36f262c in dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:308 #6 0x20a4b49 in execute ../../gcc/tree-ssa-dse.c:906 #7 0x18f223a in execute_one_pass(opt_pass*) ../../gcc/passes.c:2495 #8 0x18f2bcb in execute_pass_list_1 ../../gcc/passes.c:2584 #9 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #10 0x18f2d1f in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2595 #11 0xd34522 in cgraph_node::expand() ../../gcc/cgraphunit.c:2115 #12 0xd35b07 in expand_all_functions ../../gcc/cgraphunit.c:2251 #13 0xd38201 in symbol_table::compile() ../../gcc/cgraphunit.c:2599 #14 0xd38958 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2692 #15 0x1cdc527 in compile_file ../../gcc/toplev.c:481 #16 0x1ce2c84 in do_compile ../../gcc/toplev.c:2037 #17 0x1ce32b3 in toplev::main(int, char**) ../../gcc/toplev.c:2172 #18 0x3aaf9e0 in main ../../gcc/main.c:39 #19 0x14f842659f49 in __libc_start_main (/lib64/libc.so.6+0x20f49) #20 0x7d93b9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x7d93b9)
[Bug c/82492] New: ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82492 Bug ID: 82492 Summary: ICE Segmentation fault Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gcc at lanrules dot de Target Milestone: --- Created attachment 42328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42328&action=edit gcc stderr I build a python package, matplotlib 1.4.3, obtainable at https://github.com/matplotlib/matplotlib/archive/v1.4.3.tar.gz The call to `python2 setup.py build` in the extracted directory leads to this call: gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC -PY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib__png_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -I/usr/lib/python2.7/site-packages/numpy/core/include -I/usr/lib/python2.7/site-packages/numpy/core/include -I/usr/include/libpng16 -I/usr/local/include -I/usr/include -I. -Iextern -I/usr/include/python2.7 -c src/_png.cpp -o build/temp.linux-x86_64-2.7/src/_png.o This call leads to the output: src/_png.cpp: In member function ‘Py::Object _png_module::write_png(const Py::Tuple&)’: src/_png.cpp:103:12: internal compiler error: Segmentation fault Py::Object _png_module::write_png(const Py::Tuple& args) ^~~ Please find the full output (with -v -save-temps) attached, as well as the corresponding .ii file.
[Bug tree-optimization/82491] New: UBSAN in gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82491 Bug ID: 82491 Summary: UBSAN in gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- With bootstrap-ubsan I see: $ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. /home/marxin/Programming/gcc2/gcc/testsuite/c-c++-common/ubsan/ptr-overflow-sanitization-1.c -fsanitize=undefined -O3 -g ../../gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int' #0 0x120ea4d in get_base_constructor ../../gcc/gimple-fold.c:6187 #1 0x121127f in fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*)) ../../gcc/gimple-fold.c:6509 #2 0x1211684 in fold_const_aggregate_ref(tree_node*) ../../gcc/gimple-fold.c:6548 #3 0x11ef391 in maybe_fold_reference ../../gcc/gimple-fold.c:296 #4 0x1207bd2 in fold_stmt_1 ../../gcc/gimple-fold.c:4651 #5 0x1207fc9 in fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*)) ../../gcc/gimple-fold.c:4739 #6 0x2226772 in substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-propagate.c:1072 #7 0x36f262c in dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:308 #8 0x2227186 in substitute_and_fold(tree_node* (*)(tree_node*), bool (*)(gimple_stmt_iterator*)) ../../gcc/tree-ssa-propagate.c:1188 #9 0x2048303 in ccp_finalize ../../gcc/tree-ssa-ccp.c:960 #10 0x2054465 in do_ssa_ccp ../../gcc/tree-ssa-ccp.c:2437 #11 0x205477a in execute ../../gcc/tree-ssa-ccp.c:2480 #12 0x18f223a in execute_one_pass(opt_pass*) ../../gcc/passes.c:2495 #13 0x18f2bcb in execute_pass_list_1 ../../gcc/passes.c:2584 #14 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #15 0x18f2d1f in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2595 #16 0x18ed2ef in do_per_function_toporder(void (*)(function*, void*), void*) ../../gcc/passes.c:1737 #17 0x18f5266 in execute_ipa_pass_list(opt_pass*) ../../gcc/passes.c:2935 #18 0xd36f41 in ipa_passes ../../gcc/cgraphunit.c:2399 #19 0xd37db5 in symbol_table::compile() ../../gcc/cgraphunit.c:2534 #20 0xd38958 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2692 #21 0x1cdc527 in compile_file ../../gcc/toplev.c:481 #22 0x1ce2c84 in do_compile ../../gcc/toplev.c:2037 #23 0x1ce32b3 in toplev::main(int, char**) ../../gcc/toplev.c:2172 #24 0x3aaf9e0 in main ../../gcc/main.c:39 #25 0x14eeb648cf49 in __libc_start_main (/lib64/libc.so.6+0x20f49) #26 0x7d93b9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x7d93b9) ../../gcc/dwarf2out.c:13598:15: runtime error: signed integer overflow: 9223372036854775789 + 48 cannot be represented in type 'long int' #0 0xea2524 in based_loc_descr ../../gcc/dwarf2out.c:13598 #1 0xeb0bfd in mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) ../../gcc/dwarf2out.c:15027 #2 0xeb93ed in loc_descriptor ../../gcc/dwarf2out.c:15974 #3 0xeb70d8 in loc_descriptor ../../gcc/dwarf2out.c:15784 #4 0xeb9cb2 in dw_loc_list_1 ../../gcc/dwarf2out.c:16069 #5 0xebb348 in dw_loc_list ../../gcc/dwarf2out.c:16339 #6 0xebff4b in loc_list_from_tree_1 ../../gcc/dwarf2out.c:17454 #7 0xec33a8 in loc_list_from_tree ../../gcc/dwarf2out.c:18058 #8 0xecbe1a in add_location_or_const_value_attribute ../../gcc/dwarf2out.c:19263 #9 0xee0ca2 in gen_variable_die ../../gcc/dwarf2out.c:22928 #10 0xef0500 in gen_decl_die ../../gcc/dwarf2out.c:25393 #11 0xeecf4a in process_scope_var ../../gcc/dwarf2out.c:24849 #12 0xeed02c in decls_for_scope ../../gcc/dwarf2out.c:24875 #13 0xedcab0 in gen_subprogram_die ../../gcc/dwarf2out.c:22421 #14 0xeefd6a in gen_decl_die ../../gcc/dwarf2out.c:25310 #15 0xef296b in dwarf2out_decl ../../gcc/dwarf2out.c:25852 #16 0xef29f4 in dwarf2out_function_decl ../../gcc/dwarf2out.c:25867 #17 0x1090964 in rest_of_handle_final ../../gcc/final.c:4520 #18 0x1090f80 in execute ../../gcc/final.c:4562 #19 0x18f223a in execute_one_pass(opt_pass*) ../../gcc/passes.c:2495 #20 0x18f2bcb in execute_pass_list_1 ../../gcc/passes.c:2584 #21 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #22 0x18f2c80 in execute_pass_list_1 ../../gcc/passes.c:2585 #23 0x18f2d1f in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2595 #24 0xd34522 in cgraph_node::expand() ../../gcc/cgraphunit.c:2115 #25 0xd35b07 in expand_all_functions ../../gcc/cgraphunit.c:2251 #26 0xd38201 in symbol_table::compile() ../../gcc/cgraphunit.c:
[Bug sanitizer/82490] Please don't error out on unknown no_sanitize attributes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82490 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-09 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I'll do it.
[Bug target/82464] s390x z14: vector float: invalid parameter combination for intrinsic '__builtin_s390_vec_xor'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Oct 9 11:40:23 2017 New Revision: 253541 URL: https://gcc.gnu.org/viewcvs?rev=253541&root=gcc&view=rev Log: PR target/82464 * config/s390/s390-builtins.def (s390_vec_xor_flt_a, s390_vec_xor_flt_b, s390_vec_xor_flt_c): New. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390-builtins.def
[Bug debug/82489] New: UBSAN in gcc/dbxout.c:676:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82489 Bug ID: 82489 Summary: UBSAN in gcc/dbxout.c:676:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- With bootstrap-ubsan I can see: $ ./xgcc -B. /home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/debug/2503-1.c -gstabs1 ../../gcc/dbxout.c:676:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself
[Bug sanitizer/82490] New: Please don't error out on unknown no_sanitize attributes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82490
Bug ID: 82490
Summary: Please don't error out on unknown no_sanitize
attributes.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
markus@x4 ~ % cat test.ii
__attribute__((no_sanitize("function"))) void foo() {}
markus@x4 ~ % clang++ -c test.ii
(trunk:)
markus@x4 ~ % g++ -c test.ii
test.ii:1:51: error: wrong argument: "function"
__attribute__((no_sanitize("function"))) void foo() {}
^
markus@x4 ~ % /usr/x86_64-pc-linux-gnu/gcc-bin/7.2.1/g++ -c test.ii
test.ii:1:51: warning: ‘no_sanitize’ attribute directive ignored [-Wattributes]
__attribute__((no_sanitize("function"))) void foo() {}
^
[Bug rtl-optimization/82488] New: UBSAN in gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82488 Bug ID: 82488 Summary: UBSAN in gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Following overflows: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr17397.c -c ../../gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int' (and many other where we have an array allocated with alloca (VLA).
[Bug target/82483] ICE on invalid use w/ -mno-mmx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82483 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-09 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 42327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42327&action=edit gcc8-pr82483.patch Untested fix.
[Bug web/82487] Change generic "attachment too big" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82487 --- Comment #2 from Jonathan Wakely --- Thanks!
[Bug target/82445] ARM target generates unaligned STRD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82445 --- Comment #4 from Richard Earnshaw --- looks like gen_operands_ldrd_strd should be checking for this and failing if the alignment is not suitable for the target architecture.
[Bug web/82487] Change generic "attachment too big" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82487 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |LpSolit at netscape dot net --- Comment #1 from Frédéric Buclin --- Done.
[Bug target/82464] s390x z14: vector float: invalid parameter combination for intrinsic '__builtin_s390_vec_xor'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-10-09
Ever confirmed|0 |1
--- Comment #2 from Andreas Krebbel ---
(In reply to Jakub Jelinek from comment #1)
> ought to fix it. I'm just don't see any vec_{and,or,xor} tests in the
> testsuite, so dunno where to add test for this.
Yes that's the right fix. Feel free to commit it (without testcase).
wrt testcases: Message understood :) I really need to add testcases checking at
least the valid signatures. I plan to generate these from the documentation but
I cannot do this before the IBM z14 document has been published.
Current version can be found here (but does not cover z14 yet):
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcpx01/vectorsupport.htm
[Bug target/82440] [8 regression] ICE in aarch64_simd_valid_immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82440 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Earnshaw --- Fixed
[Bug target/82483] ICE on invalid use w/ -mno-mmx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82483
--- Comment #1 from Jakub Jelinek ---
More complete testcase, all of these ICE individually (except f19) with -mssse3
-mno-mmx:
#include
void f1 (__m64 x, __m64 y, char *z) { _mm_maskmove_si64 (x, y, z); }
int f2 (__m64 x) { return _mm_extract_pi16 (x, 1); }
__m64 f3 (__m64 x, int y) { return _mm_insert_pi16 (x, y, 1); }
__m64 f4 (__m128 x) { return _mm_cvtps_pi32 (x); }
__m64 f5 (__m128 x) { return _mm_cvttps_pi32 (x); }
__m128 f6 (__m128 x, __m64 y) { return _mm_cvtpi32_ps (x, y); }
__m64 f7 (__m64 x, __m64 y) { return _mm_avg_pu8 (x, y); }
__m64 f8 (__m64 x, __m64 y) { return _mm_avg_pu16 (x, y); }
__m64 f9 (__m64 x, __m64 y) { return _mm_mulhi_pu16 (x, y); }
__m64 f10 (__m64 x, __m64 y) { return _mm_max_pu8 (x, y); }
__m64 f11 (__m64 x, __m64 y) { return _mm_max_pi16 (x, y); }
__m64 f12 (__m64 x, __m64 y) { return _mm_min_pu8 (x, y); }
__m64 f13 (__m64 x, __m64 y) { return _mm_min_pi16 (x, y); }
__m64 f14 (__m64 x, __m64 y) { return _mm_sad_pu8 (x, y); }
int f15 (__m64 x) { return _mm_movemask_pi8 (x); }
__m64 f16 (__m64 x) { return _mm_shuffle_pi16 (x, 1); }
__m64 f17 (__m128d x) { return _mm_cvtpd_pi32 (x); }
__m64 f18 (__m128d x) { return _mm_cvttpd_pi32 (x); }
__m128d f19 (__m64 x) { return _mm_cvtpi32_pd (x); }
__m64 f20 (__m64 x, __m64 y) { return _mm_mul_su32 (x, y); }
__m64 f21 (__m64 x) { return _mm_abs_pi8 (x); }
__m64 f22 (__m64 x) { return _mm_abs_pi16 (x); }
__m64 f23 (__m64 x) { return _mm_abs_pi32 (x); }
__m64 f24 (__m64 x, __m64 y) { return _mm_hadd_pi16 (x, y); }
__m64 f25 (__m64 x, __m64 y) { return _mm_hadd_pi32 (x, y); }
__m64 f26 (__m64 x, __m64 y) { return _mm_hadds_pi16 (x, y); }
__m64 f27 (__m64 x, __m64 y) { return _mm_hsub_pi16 (x, y); }
__m64 f28 (__m64 x, __m64 y) { return _mm_hsub_pi32 (x, y); }
__m64 f29 (__m64 x, __m64 y) { return _mm_hsubs_pi16 (x, y); }
__m64 f30 (__m64 x, __m64 y) { return _mm_maddubs_pi16 (x, y); }
__m64 f31 (__m64 x, __m64 y) { return _mm_mulhrs_pi16 (x, y); }
__m64 f32 (__m64 x, __m64 y) { return _mm_shuffle_pi8 (x, y); }
__m64 f33 (__m64 x, __m64 y) { return _mm_sign_pi8 (x, y); }
__m64 f34 (__m64 x, __m64 y) { return _mm_sign_pi16 (x, y); }
__m64 f35 (__m64 x, __m64 y) { return _mm_sign_pi32 (x, y); }
These are all SSE or SSE2 or SSSE3 instructions don't require MMX CPUID, but
actually have (or in case of f6/f19 might have, the input allows memory operand
too; note f6 still ICEs though) MMX register operand(s), so with -mno-mmx can't
really work, as ix86_vector_mode_supported_p will return false for the
V2SI/V4HI/V8QImode.
I think easiest would be to require both {SSE/SSE2/SSSE3} and MMX ISAs for
these, turning a -mno-mmx switch into a hard request to never use %mm0-%mm7
registers for anything.
[Bug ipa/82476] C++: Inlining fails for a simple function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 --- Comment #6 from Arun Muralidharan --- I understand your point on why it chose not to be inlined. I was doing a micro benchmark for a sample application (a interview question basically) and thats when this issue came up. Thanks.
[Bug hsa/82416] Miscompilation due to HSA BE expanding all sub-integer types to integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82416 --- Comment #2 from Martin Jambor --- Author: jamborm Date: Mon Oct 9 09:41:44 2017 New Revision: 253538 URL: https://gcc.gnu.org/viewcvs?rev=253538&root=gcc&view=rev Log: [PR 82416] Do not extend operands to at least 32 bits 2017-10-09 Martin Jambor PR hsa/82416 gcc/ * hsa-common.h (hsa_op_with_type): New method extend_int_to_32bit. * hsa-gen.c (hsa_extend_inttype_to_32bit): New function. (hsa_type_for_scalar_tree_type): Use it. Always force min32int for COMPLEX types. (hsa_fixup_mov_insn_type): New function. (hsa_op_with_type::get_in_type): Use it. (hsa_build_append_simple_mov): Likewise. Allow sub-32bit immediates in an assert. (hsa_op_with_type::extend_int_to_32bit): New method. (gen_hsa_insns_for_bitfield): Fixup instruction and intermediary types. Convert to dest type if necessary. (gen_hsa_insns_for_bitfield_load): Fixup load type if necessary. (reg_for_gimple_ssa): Pass false as min32int to hsa_type_for_scalar_tree_type. (gen_hsa_addr): Fixup type when creating addresable temporary. (gen_hsa_cmp_insn_from_gimple): Extend operands if necessary. (gen_hsa_unary_operation): Extend operands and convert to dest type if necessary. Call hsa_fixup_mov_insn_type. (gen_hsa_binary_operation): Changed operand types to hsa_op_with_type, extend operands and convert to dest type if necessary. (gen_hsa_insns_for_operation_assignment): Extend operands and convert to dest type if necessary. (set_output_in_type): Call hsa_fixup_mov_insn_type. Just ude dest if conversion nt necessary and size matches. (gen_hsa_insns_for_load): Call hsa_fixup_mov_insn_type, convert to dest type if necessary. (gen_hsa_insns_for_store): Call hsa_fixup_mov_insn_type. (gen_hsa_insns_for_switch_stmt): Likewise. Also extend operands if necessary. (gen_hsa_clrsb): Likewise. (gen_hsa_ffs): Likewise. (gen_hsa_divmod): Extend operands and convert to dest type if necessary. (gen_hsa_atomic_for_builtin): Change type of op to hsa_op_with_type. libgomp/ * testsuite/libgomp.hsa.c/pr82416.c: New test. Added: trunk/libgomp/testsuite/libgomp.hsa.c/pr82416.c Modified: trunk/gcc/ChangeLog trunk/gcc/hsa-common.h trunk/gcc/hsa-gen.c trunk/libgomp/ChangeLog
[Bug c++/82360] [8 Regression] tree check fail in get_inner_reference, at expr.c:6996
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82360 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #5 from Tobias Burnus --- [Still occurs with today's Rev. 253536.] Bisecting (for comment 2) points to: https://gcc.gnu.org/viewcvs?rev=253266&root=gcc&view=rev commit 4cedc476c94a41551d965bc57fbbe0186983c3c4 Author: jason Date: Thu Sep 28 19:39:45 2017 + PR c++/56973, DR 696 - capture constant variables only as needed. * expr.c (mark_use): Split out from mark_rvalue_use and mark_lvalue_use. Handle lambda capture of constant variables. (mark_lvalue_use_nonread): New. * semantics.c (process_outer_var_ref): Don't capture a constant variable until forced. * pt.c (processing_nonlambda_template): New. * call.c (build_this): Check it. * decl2.c (grok_array_decl): Call mark_rvalue_use and mark_lvalue_use_nonread. * init.c (constant_value_1): Don't call mark_rvalue_use. * typeck.c (build_static_cast): Handle lambda capture. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@253266 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/82451] [GRAPHITE] codegen error in get_rename_from_scev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82451 Richard Biener changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Richard Biener --- *** Bug 82486 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/82451] [GRAPHITE] codegen error in get_rename_from_scev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82451
--- Comment #4 from Richard Biener ---
Testcase from dup.
static int a[];
int b[1];
int c;
static void
d (int *f, int *g)
{
int e;
for (e = 0; e < 2; e++)
g[e] = 1;
for (e = 0; e < 2; e++)
g[e] = f[e] + f[e + 1];
}
void
h ()
{
for (;; c += 8)
d (&a[c], b);
}
[Bug tree-optimization/82486] [8 Regression][graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82486 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- Dup. *** This bug has been marked as a duplicate of bug 82451 ***
[Bug web/82487] New: Change generic "attachment too big" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82487 Bug ID: 82487 Summary: Change generic "attachment too big" message Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: LpSolit at netscape dot net Target Milestone: --- When users attempt to upload an attachment that is too large they get a message telling them to put the file online somewhere and attach a URL to bugzilla. This is bad in several ways: - we don't want testcases provided via URLs to external resources that might disappear at any time, see https://gcc.gnu.org/bugs/ which is clear we want the preprocessed source attached here; - adding the URL as the attachment is just stupid and requires unnecessary clicks to view it. URLs are better in comments, not as attachments; - we should tell users to try compressing the file using gzip, bzip2, or something like that, because the compressed file is almost always small enough; - we should point them to https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction as well. Please could we change that message so it doesn't contradict https://gcc.gnu.org/bugs/ and so it says to try compression and/or reduction?
[Bug libstdc++/82481] dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- (In reply to heinzisoft from comment #0) > Building the following minimal example with libstdc++ 7.0.1 And why are you using that unsupported version?
[Bug libstdc++/82481] dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 --- Comment #2 from Jonathan Wakely --- It is a dangling pointer, but it can't be dereferenced, so it doesn't matter. It's only used by std::call_once and will be set to a different local variable by the next call. We could zero the pointer, but it would be a waste of cycles.
[Bug ipa/82476] C++: Inlining fails for a simple function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 --- Comment #5 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #4) > Note GCC knows main can only be called once (calling main more than once in > C/C++ is undefined IIRC) It's undefined in C++, I don't think it is in C.
[Bug web/82448] GCC web guide contains wrong information about Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82448 Alexander Samoilov changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #3 from Alexander Samoilov --- Thank you for the information. -- BR, Alexander.
[Bug rtl-optimization/82482] ICE in qsort comparator non-negative on sorted output: 1 in fast_allocation at ira-color.c:4821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82482 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Alexander Monakov --- Thanks, but this is due to the same allocator as in PR 82395, allocno_priority_compare_func (and I've confirmed it works with my patch). *** This bug has been marked as a duplicate of bug 82395 ***
[Bug tree-optimization/82422] [8 Regression][graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82422 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- New bug for this.
[Bug rtl-optimization/82395] [8 Regression] qsort comparator non-negative on sorted output: 1 in color_allocnos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82395 --- Comment #4 from Alexander Monakov --- *** Bug 82482 has been marked as a duplicate of this bug. ***
[Bug middle-end/82407] [8 Regression][meta-bug] qsort_chk fallout tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407 Bug 82407 depends on bug 82482, which changed state. Bug 82482 Summary: ICE in qsort comparator non-negative on sorted output: 1 in fast_allocation at ira-color.c:4821 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82482 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/82486] [8 Regression][graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82486 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-10-09 Version|unknown |8.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug sanitizer/82484] [8 Regression] ICE in verify_gimple failed w/ -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82484 Richard Biener changed: What|Removed |Added Version|unknown |8.0 Target Milestone|--- |8.0
[Bug middle-end/82479] missing popcount builtin detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 Richard Biener changed: What|Removed |Added Version|unknown |8.0 --- Comment #7 from Richard Biener --- Technically loop distribution would be one place to add this. Or SCEV cprop. The pattern matching should be quite cheap - the question is of course how many different ways to express popcount exist... so it does somewhat feel like a SPEC hack...
[Bug tree-optimization/82473] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82473 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine then.
[Bug tree-optimization/82486] New: [8 Regression][graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82486
Bug ID: 82486
Summary: [8 Regression][graphite] ICE in set_codegen_error, at
graphite-isl-ast-to-gimple.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
I've got one another ICE:
$ cat ice.c
static int a[];
int b[1];
int c;
static void
d (int *f, int *g)
{
int e;
for (e = 0; e < 2; e++)
g[e] = 1;
for (e = 0; e < 2; e++)
g[e] = f[e] + f[e + 1];
}
void
h ()
{
for (;; c += 8)
d (&a[c], b);
}
$ /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B
/home/marxin/Programming/gcc2/objdir/gcc/ -floop-parallelize-all -O1 -mavx512vl
ice.c
during GIMPLE pass: graphite
ice.c: In function ‘h’:
ice.c:14:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:216
h ()
^
0x5cb6d5 translate_isl_ast_to_gimple::set_codegen_error()
../../gcc/graphite-isl-ast-to-gimple.c:215
0x13252d5 translate_isl_ast_to_gimple::set_codegen_error()
../../gcc/graphite-isl-ast-to-gimple.c:215
0x13252d5 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, basic_block_def*, basic_block_def*, vec)
../../gcc/graphite-isl-ast-to-gimple.c:1097
0x1325a14
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec)
../../gcc/graphite-isl-ast-to-gimple.c:1245
0x1327850
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
../../gcc/graphite-isl-ast-to-gimple.c:1313
0x1328274
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:803
0x1328545 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:617
0x13287a2 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:720
0x13288a5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:832
0x1328d8a graphite_regenerate_ast_isl(scop*)
../../gcc/graphite-isl-ast-to-gimple.c:1559
0x13238ae graphite_transform_loops()
../../gcc/graphite.c:442
0x1324820 graphite_transforms
../../gcc/graphite.c:486
0x1324820 execute
../../gcc/graphite.c:563
$ /home/marxin/Programming/gcc2/objdir/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/marxin/Programming/gcc2/objdir/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-bootstrap
--disable-libsanitizer --disable-multilib
Thread model: posix
gcc version 8.0.0 20171009 (experimental) (GCC)
[Bug tree-optimization/82450] loop flattening should be done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82450 --- Comment #2 from Richard Biener --- We once had a very aggressive pass to do this as part of graphite transforms, it's on the GCC 4.7 branch.
[Bug tree-optimization/82485] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82485 Jakub Jelinek changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Daniel, can you please have a look at this? Thanks.
[Bug tree-optimization/82485] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82485
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-10-09
CC||dansan at gcc dot gnu.org
Target Milestone|--- |8.0
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
On a slightly modified testcase this starts already at r251321.
struct S { char s[0x4000]; } s;
void
foo (struct S *p)
{
char b[0x07fff000L];
*(struct S *)&b[0x07ffef00L] = s;
*p = *(struct S *)&b[0x07ffefffL];
}
[Bug middle-end/82479] missing popcount builtin detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #6 from Wilco --- (In reply to Andrew Pinski from comment #5) > Was added to LLVM back in 2012: > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20121119/156272.html > > Again I don't know how useful it is compared to the compile time that it > would take. I'd be more worried that the LLVM sequence isn't better in common usage. Given it has a fixed high latency, you need quite a few set bits before it's faster.
[Bug tree-optimization/82472] [8 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82472 amker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #2 from amker at gcc dot gnu.org --- Sorry for the breakage, I will investigate it.
[Bug tree-optimization/82422] [8 Regression][graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82422
Martin Liška changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #4 from Martin Liška ---
I've got one another ICE:
$ cat ice.c
static int a[];
int b[1];
int c;
static void
d (int *f, int *g)
{
int e;
for (e = 0; e < 2; e++)
g[e] = 1;
for (e = 0; e < 2; e++)
g[e] = f[e] + f[e + 1];
}
void
h ()
{
for (;; c += 8)
d (&a[c], b);
}
$ /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B
/home/marxin/Programming/gcc2/objdir/gcc/ -floop-parallelize-all -O1 -mavx512vl
ice.c
during GIMPLE pass: graphite
ice.c: In function ‘h’:
ice.c:14:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:216
h ()
^
0x5cb6d5 translate_isl_ast_to_gimple::set_codegen_error()
../../gcc/graphite-isl-ast-to-gimple.c:215
0x13252d5 translate_isl_ast_to_gimple::set_codegen_error()
../../gcc/graphite-isl-ast-to-gimple.c:215
0x13252d5 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, basic_block_def*, basic_block_def*, vec)
../../gcc/graphite-isl-ast-to-gimple.c:1097
0x1325a14
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec)
../../gcc/graphite-isl-ast-to-gimple.c:1245
0x1327850
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
../../gcc/graphite-isl-ast-to-gimple.c:1313
0x1328274
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:803
0x1328545 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:617
0x13287a2 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:720
0x13288a5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/graphite-isl-ast-to-gimple.c:832
0x1328d8a graphite_regenerate_ast_isl(scop*)
../../gcc/graphite-isl-ast-to-gimple.c:1559
0x13238ae graphite_transform_loops()
../../gcc/graphite.c:442
0x1324820 graphite_transforms
../../gcc/graphite.c:486
0x1324820 execute
../../gcc/graphite.c:563
$ /home/marxin/Programming/gcc2/objdir/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/marxin/Programming/gcc2/objdir/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-bootstrap
--disable-libsanitizer --disable-multilib
Thread model: posix
gcc version 8.0.0 20171009 (experimental) (GCC)
[Bug fortran/82480] KIND array returned by STAT too small for many values on CygWin platforms (and probably others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-09 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Related to pr30372.
Re: GCC does not optimize out functions without side effects with asm statements inside loop even if return velue is ignored
On Sat, 7 Oct 2017, Andrew Pinski wrote: > On Sat, Oct 7, 2017 at 2:22 PM, Saldyrkine, Mikhail > wrote: > > The " uint64_t test_noasm(uint64_t idx)" has same loop and the function is > > optimized out. > > There is a difference there, objects is limited to 1024. Loading past > the array bounds is undefined. But that possibility doesn't seem to me a valid reason to keep the asm from being optimized away. If I were the OP, I'd file an enhancement request in the bugzilla. brgds, H-P
[Bug fortran/82372] Rejects valid parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82372 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- I am testing a patch.
