[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88738 --- Comment #10 from drepper at gcc dot gnu.org --- Author: drepper Date: Wed Jan 16 08:01:22 2019 New Revision: 267964 URL: https://gcc.gnu.org/viewcvs?rev=267964&root=gcc&view=rev Log: PR libstdc++/88738 treat shared_ptr and unique_ptr more like plain old pointers PR libstdc++/88738 Warn about unused comparisons of shared_ptr/unique_ptr * include/bits/c++config [_GLIBCXX_NODISCARD]: Define. * include/bits/shared_ptr.h: Use it for operator ==, !=, <, <=, >, >= for shared_ptr. * include/bits/unique_ptr.h: Likewise for unique_ptr. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/include/bits/shared_ptr.h trunk/libstdc++-v3/include/bits/unique_ptr.h
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #24 from Jakub Jelinek --- Created attachment 45438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45438&action=edit gcc9-pr88714-poc.patch Proof of concept that fixes the short testcase. One would need to write remaining non-thumb patterns (strd in vfp.md, ldrd + strd in arm.md and ldrd + strd in iwmmxt.md, all close to the movdi patterns, unless there is a possibility to unify them (but, e.g. iwmmxt.md uses r instead of q, etc.?)) and do it always in ldrdst*.md. Not really sure about the predicates, constraints etc. either., will defer that to those familiar with the backend and architecture.
[Bug rtl-optimization/88870] [7/8/9 Regression] ICE: Segmentation fault (in df_worklist_propagate_backward)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88870 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-16 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.5 Summary|ICE: Segmentation fault (in |[7/8/9 Regression] ICE: |df_worklist_propagate_backw |Segmentation fault (in |ard)|df_worklist_propagate_backw ||ard) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to ICE in between r184930 (last good) and r184937 (first ICE). So either r184932, or r184933, or 184937.
[Bug target/88778] Odd Complex float load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88778
--- Comment #8 from 刘袋鼠 ---
(In reply to H.J. Lu from comment #5)
> Please take a look at
>
> https://github.com/hjl-tools/gcc/commit/
> a56b4a49b2617a31365bdb9c44340695c31d56e8
How did you handle MOV reg(SCmode) < CONST_RTX(SCmode), I got an error
report bellow insn wasn't recognized.
(insn 31 16 17 2 (set (reg:SC 91 [ c ])
(concat:SC (const_double:SF 0.0 [0x0.0p+0])
(const_double:SF 0.0 [0x0.0p+0]))) "complex.c":5:5 -1
(nil))
reference patch is at
https://github.com/algebra84/gcc/commit/2dcce0fc964b4d3034344a8c242edf6e6d0c
Simple case bellow will reproduce problem:
cat complex.c
_Complex float
foo (_Complex float a, _Complex float b)
{
_Complex float c,d;
c = a + b;
return c;
}
[Bug c++/88872] [8 Regression] ICE with g++ 8.x in cp_build_addr_expr_1, at cp/typeck.c:5936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88872 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-16 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.3 Summary|ICE with g++ 8.x in |[8 Regression] ICE with g++ |cp_build_addr_expr_1, at|8.x in |cp/typeck.c:5936|cp_build_addr_expr_1, at ||cp/typeck.c:5936 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Confirmed on the 8.x branch (including Jun 15 2018 and Jan 8 2019 snapshots), but doesn't ICE in 7.x, nor at 8.x branchpoint, nor at current trunk. On the trunk it started to ICE with r260672 and got fixed with r265788 (but given the number of issues that revision exposed I think it isn't really backportable). The testcase should be added to trunk testsuite I guess.
[Bug fortran/88871] [9.0 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 --- Comment #2 from Jürgen Reuter --- Here is a more minimal example: SUBROUTINE MNREAD(IFLGIN,IFLGUT) IMPLICIT DOUBLE PRECISION (A-H,O-Z) PARAMETER (MNE=100 , MNI=50) PARAMETER (MNIHL=MNI*(MNI+1)/2) CHARACTER*10 CPNAM COMMON 1/MN7NAM/ CPNAM(MNE) 2/MN7EXT/ U(MNE) CHARACTER CRDBUF*80, CUPBUF*10 CUPBUF(1:10) = CRDBUF(1:10) RETURN END or also to completely implicit typing SUBROUTINE MNREAD(IFLGIN,IFLGUT) PARAMETER (MNE=100 , MNI=50) PARAMETER (MNIHL=MNI*(MNI+1)/2) CHARACTER*10 CPNAM COMMON 1/MN7NAM/ CPNAM(MNE) 2/MN7EXT/ U(MNE) CHARACTER CRDBUF*80, CUPBUF*10 CUPBUF(1:10) = CRDBUF(1:10) RETURN END
[Bug c++/88869] ICE (Segmentation Fault) when using lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88869
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-16
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Reduced testcase (-std=c++17):
using A = int;
template struct B;
template <> struct B {
template struct C { C (); };
auto foo () { C (); }
};
That is ice-on-invalid, dunno if the original is invalid too or not.
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #25 from ktkachov at gcc dot gnu.org --- Thanks, I've reproduced the failure with the reduced testcase (aborts at -O2 but not at -O0)
[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #17 from Uroš Bizjak ---
(In reply to vehre from comment #9)
> Author: vehre
> Date: Fri Jan 13 10:22:21 2017
> New Revision: 244407
>
> URL: https://gcc.gnu.org/viewcvs?rev=244407&root=gcc&view=rev
> Log:
> gcc/testsuite/ChangeLog:
>
> 2017-01-13 Andre Vehreschild
>
> PR fortran/70696
> * gfortran.dg/coarray/event_3.f08: New test.
What is this test supposed to test? The _.optimized dump shows only:
--cut here--
;; Function main (main, funcdef_no=2, decl_uid=952, cgraph_uid=3,
symbol_order=2) (executed once)
__attribute__((externally_visible))
main (integer(kind=4) argc, character(kind=1) * * argv)
{
struct FRAME.global_event FRAME.1;
static integer(kind=4) options.0[7] = {2116, 4095, 0, 1, 1, 0, 31};
integer(kind=4) _8;
[local count: 1073741824]:
_gfortran_set_args (argc_2(D), argv_3(D));
_gfortran_set_options (7, &options.0[0]);
_8 = FRAME.1.x;
if (_8 != 0)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 429497]:
_gfortran_error_stop_numeric (1, 0);
[local count: 1073312328]:
return 0;
}
--cut here--
which results in uninitialized load from FRAME.1. The resulting x86_64 assembly
is:
main:
.LFB2:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_gfortran_set_args
movl$options.0.3867, %esi
movl$7, %edi
call_gfortran_set_options
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
which does not test anything. While x86_64 optimizers are able to eliminate
uninitialized load, it remains in alpha assembly:
main:
.frame $30,32,$26,0
.mask 0x400,-32
$LFB2:
.cfi_startproc
ldah $29,0($27) !gpdisp!1#,,
lda $29,0($29) !gpdisp!1#,,
$main..ng:
lda $30,-32($30) #,,
.cfi_def_cfa_offset 32
ldq $27,_gfortran_set_args($29) !literal!3 #,,,
stq $26,0($30) #,
.cfi_offset 26, -32
.prologue 1
# event_3.f08:10: call exchange
jsr $26,($27),_gfortran_set_args!lituse_jsr!3#,,
ldah $29,0($26) !gpdisp!4#
lda $16,7($31) #,
lda $29,0($29) !gpdisp!4#,,
ldah $17,options.0.956($29) !gprelhigh # tmp75,,
lda $17,options.0.956($17) !gprellow#,, tmp75
ldq $27,_gfortran_set_options($29) !literal!5 #,,,
jsr $26,($27),_gfortran_set_options !lituse_jsr!5#,,
ldah $29,0($26) !gpdisp!6#
# event_3.f08:17: if (cnt /= 2) error stop 1
ldl $1,16($30) # FRAME.1.x, FRAME.1.x
# event_3.f08:10: call exchange
lda $29,0($29) !gpdisp!6#,,
# event_3.f08:17: if (cnt /= 2) error stop 1
bis $31,$31,$31
bne $1,$L4 #, FRAME.1.x,
# event_3.f08:10: call exchange
mov $31,$0 #,
ldq $26,0($30) #,
lda $30,32($30) #,,
.cfi_remember_state
.cfi_restore 26
.cfi_def_cfa_offset 0
ret $31,($26),1
$L4:
.cfi_restore_state
# event_3.f08:17: if (cnt /= 2) error stop 1
mov $31,$17 #,
ldq $27,_gfortran_error_stop_numeric($29) !literal!2
#,,,
lda $16,1($31) #,
jsr $26,($27),_gfortran_error_stop_numeric !lituse_jsr!2
#,,
.cfi_endproc
$LFE2:
bis $31,$31,$31
.end main
Please note:
ldl $1,16($30) # FRAME.1.x, FRAME.1.x
...
bne $1,$L4 #, FRAME.1.x,
Which loads uninitialized value from the stack and later branches on non-zero
value. When the testcase is sun inside the debugger, it is evident that a
garbage value is loaded from the 16($30) stack location.
[Bug fortran/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68887 Bug 68887 depends on bug 70696, which changed state. Bug 70696 Summary: [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug tree-optimization/88873] New: missing vectorization for decomposed operations on a vector type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873
Bug ID: 88873
Summary: missing vectorization for decomposed operations on a
vector type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
To compute a vectorized fma, one needs to apply it on the decomposed vector
components. Here's an example with a structure type and with a vector type. The
structure type solution is just given for comparison. This bug is about the
vector type solution.
#include
typedef struct { double x, y; } s_t;
typedef double v2df __attribute__ ((vector_size (2 * sizeof(double;
s_t foo (s_t a, s_t b, s_t c)
{
return (s_t) { fma(a.x, b.x, c.x), fma (a.y, b.y, c.y) };
}
v2df bar (v2df a, v2df b, v2df c)
{
v2df r;
r[0] = fma (a[0], b[0], c[0]);
r[1] = fma (a[1], b[1], c[1]);
return r;
}
With -O3, I get on x86_64:
* For function foo (struct type):
[...]
vfmadd132pd -40(%rsp), %xmm7, %xmm6
[...]
This is vectorized as expected, though this solution is affected by bug 65847.
* For function bar (vector type):
bar:
.LFB1:
.cfi_startproc
vmovapd %xmm0, %xmm3
vunpckhpd %xmm0, %xmm0, %xmm0
vfmadd132sd %xmm1, %xmm2, %xmm3
vunpckhpd %xmm1, %xmm1, %xmm1
vunpckhpd %xmm2, %xmm2, %xmm2
vfmadd132sd %xmm1, %xmm2, %xmm0
vunpcklpd %xmm0, %xmm3, %xmm0
ret
.cfi_endproc
This is not vectorized: one has 2 vfmadd132sd instead of a single vfmadd132pd.
Note: The problem is the same with addition, but in the addition case, one can
simply do a + b. This is not possible with fma.
This bug seems similar to bug 77399.
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-16 CC||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from rsandifo at gcc dot gnu.org --- FWIW, I agree that pure unrolling doesn't feel like a gimple-level optimisation. Whether it's a win or not depends on whether the unrolled loop will make better use of the microarchitecture. The problem isn't just that that's hard to decide at the gimple level, but that the result can't be represented directly in gimple. AIUI there's no real significance to the schedule of gimple statements (beyond ensuring valid SSA and functional correctness). This is different from vectorisation and ivopts, which can represent the benefit of the transformation directly in gimple (using vector ops and TARGET_MEM_REFs respectively). As Kyrill pointed out off-list, LLVM does the unrolling in the vectoriser rather than a separate unrolling pass. (Use -mllvm -print-after-all to see this.) I think for AArch64 we can view LDP and STP as 2-element vector loads and stores that have zero-cost insertion and extraction. So converting: ldr x0, [...] add x0, x0, 1 str x0, [...] into: ldp x0, x1, [...] add x0, x0, 1 add x1, x1, 1 stp x0, x1, [...] is IMO genuine vectorisation. The LDPs and STPs are effectively scalar IFN_LOAD_LANES and IFN_STORE_LANES, although we could also represent them as single-element (V1) vector ops instead if that seems more consistent. Vectorising operations other than loads and stores would simply involve duplicating the statements VF times.
[Bug c/88874] New: support FMA on vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88874 Bug ID: 88874 Summary: support FMA on vector types Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net Target Milestone: --- Please support FMA on vector types (vector extensions). FYI, there is a already a similar PR for sqrt: PR 54408. Note also that autovectorization on decomposed vector types does not work currently: PR 88873.
[Bug tree-optimization/88873] missing vectorization for decomposed operations on a vector type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873 --- Comment #1 from Vincent Lefèvre --- Note: with Clang, I get vectorized code as expected: bar:# @bar .cfi_startproc # %bb.0: vfmadd213pd %xmm2, %xmm1, %xmm0 # xmm0 = (xmm1 * xmm0) + xmm2 retq .Lfunc_end1: .size bar, .Lfunc_end1-bar .cfi_endproc
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #18 from Дилян Палаузов --- I will sum up the discussion so far on this and other tickets: When one distributes source code software packages, the developers directly or indirectly use AR to create static libraries, when the user wants static libraries. Think on autoconf/libtool packages, where the users of those packages = software developers do not deal with AR. When a mortal user wants to build something with LTO, the user has to pass -flto to the compiler, for any source code package. Doing the LTO build process more complex than that leads to a situation, where LTO is not utilized, due to the complixity of running it. Some distributions install the linker plugin under $libdir/bfd-plugins and make ar/nm/ranlib deal transparently with -flto, but putting the plugin under $libdir/bfd-plugin for using ar/ranlib/nm is apparently kind of secret or too complicated, as not all distributions do this. So sticking to AR for building with LTO is currently not portable. When CMake is used, it chooses the appropriate gcc-ar-4, gcc-ar, llvm-ar-4.0 or llvm-ar (see https://gitlab.kitware.com/cmake/cmake/commit/630235bd9e049a8da47 and https://gitlab.kitware.com/cmake/cmake/commit/75accaae8b6a691b031f2) and ensures, that the just passing -flto will enable LTO. As can be seen from the commits above, instead of installing the linker plugin under $libdir/bfd-plugins, distributions rename gcc-ar to something different. CPython’s autoconf tries to detect if LTO is used and either switches to llvm-lto or (with GCC) uses fat lto objects, but does not use gcc-ar. Likewise valgrind’s ./configure uses gcc-ar, but not llvm-ar, so does libical’s Cmakefile (to enable LTO in old cmake versions). So the solution of compiling platform independent software is not in the distributions, the solution is to do incomplete hacks in the configure steps, and apparently meson has some knowledge how to do this (büt does not append the version number), cmake has the most complete knowledge and experimenting with autoconf nobody provides portable software where LTO is works both under LLVM and GCC. Thus the intention of tweaking ./configure is to achieve portability but nobody managed to achieve it in an optimal way yet. Installing the linker plugin under $libdir/bfd-plugins by the compiler will suggest to all distributions that the linker plugin has to be there and the distributions will ensure that at all time there is a linker plugin, while it is in practice irrelevant from which GCC version the linker plugin comes. It is irrelevant, because the plugin there is only used by ar/nm/ranlib and the differences between the versions of liblto_plugin are insignificant to ar/nm/ranlib. There are now two options: * installing the linker plugin by gcc’s “make install” in $libdir/bfd-plugin which will lead in mid-term to having AR deal with LTO in a portable way * not installing the linker plugin by gcc’s “make install” in $libdir/bfd-plugin. The only portable/cross-platform way to build with LTO is using cmake. Seriously. That said, there are advantages when gcc’s “make install” inserts its plugin in $libdir/bfd-plugins and no disadvantages. While not doing so has only disadvantages. Please explain whe gcc’s “make install” does not insert its linker plugin on the rigth place and how are supposed software developers to write software/build systems, that support LTO on any platform. Finally, not installing the plugin under $libdir/bfd-plugins because of differences in the versions, forces users to use gcc-ar, but it has the very same problems with differences in the versions.
[Bug c/54408] sqrt for vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54408 --- Comment #4 from Richard Biener --- __builtin_tg_sqrt () maybe. The difficulty is in expected behavior for "standard" -O[0] when you supply vector arguments. I think the most "convenient" thing to do is to say that __builtin_tg_sqrt () when not invoked on scalar types can (but also might not) affect errno but in unpredictable ways. OTOH for sqrt the only documented errno is EDOM thus the result would be that errno is EDOM if at least one component caused a domain error. That would support lowering non-scalar variants to component-wise operation and also gives eventual support from math libraries the necessary freedom.
[Bug c++/88869] [7/8/9 Regression] ICE (Segmentation Fault) when using lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88869
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P5
CC||jason at gcc dot gnu.org
Target Milestone|--- |7.5
Summary|ICE (Segmentation Fault)|[7/8/9 Regression] ICE
|when using lambda |(Segmentation Fault) when
||using lambda
--- Comment #2 from Jakub Jelinek ---
Started to ICE with r249816 aka PR81180 fix which has been backported to 7.x
where it ICEs now too.
Better testcase which is accepted by clang++:
using A = int;
template struct B;
template <> struct B {
template struct C {
T e;
C (T f) : e(f) {}
};
auto foo () { C ([] {}); }
};
[Bug tree-optimization/88873] missing vectorization for decomposed operations on a vector type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-16
Blocks||53947
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. bar is not vectorized because it looks like
[local count: 1073741824]:
_1 = BIT_FIELD_REF ;
_2 = BIT_FIELD_REF ;
_3 = BIT_FIELD_REF ;
_4 = fma (_3, _2, _1);
r_14 = BIT_INSERT_EXPR ;
_5 = BIT_FIELD_REF ;
_6 = BIT_FIELD_REF ;
_7 = BIT_FIELD_REF ;
_8 = fma (_7, _6, _5);
r_15 = BIT_INSERT_EXPR ;
return r_15;
and there are no loads/stores BB vectorization can work with. There's
an enhancement request for BB vectorization to key off
vector constructors and this one is similar. Eventually
r_14 = BIT_INSERT_EXPR ;
r_15 = BIT_INSERT_EXPR ;
should be combined to
r_15 = { _4, _8 };
but then dependence on BB SLP of vector CONSTRUCTORs remains. There's
also still no loads but eventually the BIT_FIELD_REFs are enough here.
Appearantly not:
v2df r;
v2df bar (v2df a, v2df b, v2df c)
{
r[0] = fma (a[0], b[0], c[0]);
r[1] = fma (a[1], b[1], c[1]);
return r;
}
results in
[local count: 1073741824]:
_1 = BIT_FIELD_REF ;
_2 = BIT_FIELD_REF ;
_3 = BIT_FIELD_REF ;
_4 = fma (_3, _2, _1);
_5 = BIT_FIELD_REF ;
_6 = BIT_FIELD_REF ;
_7 = BIT_FIELD_REF ;
_8 = fma (_7, _6, _5);
_16 = {_4, _8};
vect_cst__17 = _16;
MEM[(vector(2) double *)&r] = vect_cst__17;
_12 = r;
return _12;
so we only vectorize the store:
t.c:18:10: missed: Build SLP failed: not grouped load _3 = BIT_FIELD_REF
;
but that should be possible to fix as well.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/88872] [8 Regression] ICE with g++ 8.x in cp_build_addr_expr_1, at cp/typeck.c:5936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88872 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Known to work||7.4.0, 8.1.0, 9.0 Known to fail||8.2.0
[Bug rtl-optimization/88870] [7/8/9 Regression] ICE: Segmentation fault (in df_worklist_propagate_backward)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88870 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 45439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45439&action=edit gcc9-pr88870.patch Untested fix.
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0 Summary|[9.0 regression] ICE|[9 regression] ICE |segmentation fault in f951 |segmentation fault in f951 --- Comment #3 from Richard Biener --- Seems to work on the branches but I can't reproduce on trunk either.
[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- If what you are compiling has multiple sources and if e.g. -O0 helps, then you could bisect among the object files to find the problematic *.o file. That can be then preprocessed e.g. with -save-temps. Further analysis can be done by using bisection in the file using #pragma GCC optimize (0) and/or __attribute__((optimize (0))) to find problematic function/method.
[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 --- Comment #8 from Jakub Jelinek --- Or if 7.3 works and 8.x doesn't and the two are ABI compatible (dunno about mingw), then you could after you find problematic *.ii file try to bisect which compiler revision changed the behavior and from there you we could try to discover what changed.
[Bug rtl-optimization/88870] [7/8/9 Regression] ICE: Segmentation fault (in df_worklist_propagate_backward)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88870
--- Comment #3 from Richard Biener ---
fast_dce gathers postorder and friends computing all_blocks before it
eventually does
if (global_changed)
{
/* Turn off the RUN_DCE flag to prevent recursive calls to
dce. */
int old_flag = df_clear_flags (DF_LR_RUN_DCE);
/* So something was deleted that requires a redo. Do it on
the cheap. */
delete_unmarked_insns ();
^^^
which alters the CFG, removing edges/blocks here:
#0 remove_edge (e= 5)>)
at /space/rguenther/src/svn/gcc-8-branch/gcc/cfghooks.c:423
#1 0x00a16458 in purge_dead_edges (
bb=)
at /space/rguenther/src/svn/gcc-8-branch/gcc/cfgrtl.c:3080
#2 0x00a0fcb9 in delete_insn_and_edges (insn=0x769d51f8)
at /space/rguenther/src/svn/gcc-8-branch/gcc/cfgrtl.c:233
#3 0x01b8f314 in delete_unmarked_insns ()
at /space/rguenther/src/svn/gcc-8-branch/gcc/dce.c:636
where we'd eventually alos purge unreachable blocks.
but then we simply continue
bitmap_clear (marked);
bitmap_clear (processed);
bitmap_clear (redo_out);
/* We do not need to rescan any instructions. We only need
to redo the dataflow equations for the blocks that had a
change at the top of the block. Then we need to redo the
iteration. */
if (word_level)
df_analyze_problem (df_word_lr, all_blocks, postorder, n_blocks);
else
df_analyze_problem (df_lr, all_blocks, postorder, n_blocks);
and here things blow up because DF is still set up on the old CFG or
we are at least passing in old CFG state (all_blocks, postorder, n_blocks)
here.
[Bug c++/88869] [7/8/9 Regression] ICE (Segmentation Fault) when using lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88869 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P5 |P2
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 --- Comment #4 from Jürgen Reuter --- (In reply to Richard Biener from comment #3) > Seems to work on the branches but I can't reproduce on trunk either. That is strange. Did you try to compile several times? Sometimes it comes, sometimes it doesn’t. I did svn up and compiled the gcc, maybe I have to recompile all?
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 --- Comment #14 from Tamar Christina --- Hi Jonathan, You're right, I was going off the results of a script but it doesn't seem to have detected the change between FAIL -> UNSUPPORTED and left the state as FAIL. Sorry, I've manually checked it now.
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-16 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- ==16636== Invalid read of size 8 ==16636==at 0x93E930: resolve_ref(gfc_expr*) (resolve.c:5058) ==16636==by 0x93FCFB: resolve_variable(gfc_expr*) (resolve.c:5536) ==16636==by 0x942C1E: gfc_resolve_expr(gfc_expr*) (resolve.c:6852) ==16636==by 0x94D1F0: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.c:11283) ==16636==by 0x95AB35: resolve_codes(gfc_namespace*) (resolve.c:16733) ==16636==by 0x95AC5F: gfc_resolve(gfc_namespace*) (resolve.c:16768) ==16636==by 0x92A436: resolve_all_program_units(gfc_namespace*) (parse.c:6073) ==16636==by 0x92AC01: gfc_parse_file() (parse.c:6323) ==16636==by 0x989C74: gfc_be_parse_file() (f95-lang.c:204) ==16636==by 0x11F99D2: compile_file() (toplev.c:456) ==16636==by 0x11FC4F8: do_compile() (toplev.c:2176) ==16636==by 0x11FC7EB: toplev::main(int, char**) (toplev.c:2311) ==16636== Address 0x519cc98 is 728 bytes inside a block of size 736 free'd ==16636==at 0x4839A0C: free (vg_replace_malloc.c:540) ==16636==by 0x8ABA40: gfc_free_ref_list(gfc_ref*) (expr.c:606) ==16636==by 0x93E914: resolve_ref(gfc_expr*) (resolve.c:5082) ==16636==by 0x93FCFB: resolve_variable(gfc_expr*) (resolve.c:5536) ==16636==by 0x942C1E: gfc_resolve_expr(gfc_expr*) (resolve.c:6852) ==16636==by 0x94D1F0: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.c:11283) ==16636==by 0x95AB35: resolve_codes(gfc_namespace*) (resolve.c:16733) ==16636==by 0x95AC5F: gfc_resolve(gfc_namespace*) (resolve.c:16768) ==16636==by 0x92A436: resolve_all_program_units(gfc_namespace*) (parse.c:6073) ==16636==by 0x92AC01: gfc_parse_file() (parse.c:6323) ==16636==by 0x989C74: gfc_be_parse_file() (f95-lang.c:204) ==16636==by 0x11F99D2: compile_file() (toplev.c:456) ==16636== Block was alloc'd at ==16636==at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==16636==by 0x2194710: xcalloc (xmalloc.c:162) ==16636==by 0x92C245: match_substring(gfc_charlen*, int, gfc_ref**, bool) (primary.c:861) ==16636==by 0x92F18B: gfc_match_varspec(gfc_expr*, int, bool, bool) (primary.c:2428) ==16636==by 0x932B29: match_variable(gfc_expr**, int, int) (primary.c:3977) ==16636==by 0x932B7F: gfc_match_variable(gfc_expr**, int) (primary.c:3992) ==16636==by 0x8EB50B: gfc_match(char const*, ...) (match.c:1165) ==16636==by 0x8EBA5C: gfc_match_assignment() (match.c:1343) ==16636==by 0x91D87F: match_word(char const*, match (*)(), locus*) (parse.c:65) ==16636==by 0x91E35D: decode_statement() (parse.c:361) ==16636==by 0x923453: next_fixed() (parse.c:1425) ==16636==by 0x923558: next_statement() (parse.c:1473)
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jonathan Wakely --- Great, thanks for confirming it.
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-16 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Yeah, like that problematic source, all gfortran options used to compile that, any needed modules too + stubbed whatever it calls and whatever is needed in MAIN__ or main to reproduce, ideally with minimal dependencies. If you know the exact problematic routine, see in the debugger how many times it is called and in which invocation of the routine it misbehaves and try to capture on which arguments it is called. If you don't know the exact problematic routine, one can e.g. play with assembly bisection between -funroll-loops and no -funroll-loops, rename .L* labels in one of them so that it can be merged by hand more easily. I think gfortran doesn't have optimize (0) attribute yet.
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- Could be a result of my recent commit, r267953. I'll take a look tonight.
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 --- Comment #7 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #6) > Could be a result of my recent commit, r267953. I'll take a look tonight. That would be my guess, too, I think it has to do with the array descriptor together with implicit typing and maybe together the common block.
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #8 from Dominique d'Humieres ---
> My suspicion goes toward the fix for PR81849
Debugger shows
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
frame #0: 0x0001000b2e1d f951`::resolve_ref(expr=0x000142c1c580) at
resolve.c:5060
5057
5058
5059 for (ref = expr->ref, prev = &expr->ref; ref; prev = &ref->next, ref
= ref->next)
-> 5060 switch (ref->type)
5061 {
5062 case REF_ARRAY:
5063 if (!resolve_array_ref (&ref->u.ar))
so Il'd blame rather r267953.
The test gcc/testsuite/gfortran.dg/actual_array_substr_3.f90 fails at the same
place.
[Bug c++/88875] New: [8 regression] initializer_list and explicit ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875
Bug ID: 88875
Summary: [8 regression] initializer_list and explicit ctor
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Created attachment 45440
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45440&action=edit
testcase
We reject default member list initializers when the member has an explicit ctor
taking a list. We accept such an initialier on an explicit member initializer.
GCC-8 accepted this.
g++ -std=c++17 -c gb.cc -save-temps
gb.cc:10:14: error: converting to 'X' from initializer list would use explicit
constructor 'X::X(const std::initializer_list&)'
10 | X x { 1, 2 }; // error
member initialization is direct-initialization:
The expression-list or braced-init-list in a mem-initializer is used to
initialize the designated subobject (or, in the case of a delegating
constructor, the complete class object) according to the initialization rules
of 9.3 for direct-initialization. [class.base.init]/7
/copy/-list-initialization prohibits resolving to an explicit-ctor:
In copy-list-initialization, if an explicit constructor is chosen, the
initialization is ill-formed. [over.match.list]/2
but there's no such restriction for direct initialization.
[Bug c++/88875] [9 regression] initializer_list and explicit ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-16 Known to work||8.2.1 Target Milestone|--- |9.0 Summary|[8 regression] |[9 regression] |initializer_list and|initializer_list and |explicit ctor |explicit ctor Ever confirmed|0 |1
[Bug c++/88875] [9 regression] initializer_list and explicit ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r260126.
[Bug lto/88876] New: [9 regression] ICE in propagate_pure_const ipa-pure-const.c:1502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88876
Bug ID: 88876
Summary: [9 regression] ICE in propagate_pure_const
ipa-pure-const.c:1502
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
r261210 PASS
r261341 FAIL
r267961 FAIL
$ cat a.i
extern int c();
int a;
int b() {
if (a)
if (c())
return 0;
return 1;
}
#pragma GCC optimize "O0"
int c() {return 0;}
$ /usr/local/gcc_current/bin/gcc -fpreprocessed -O2 -fno-semantic-interposition
-fPIC -DPIC -flto -c a.i -o a.o
$ /usr/local/gcc_current/bin/gcc -fPIC -DPIC -shared -nostdlib -flto a.o
during IPA pass: pure-const
lto1: internal compiler error: Segmentation fault
0xec389f crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:326
0x7f57c15535bf ???
/usr/src/debug/glibc-2.28-60-g4d7af7815a/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x184197e propagate_pure_const
/home/dimhen/src/gcc_current/gcc/ipa-pure-const.c:1502
0x184197e execute
/home/dimhen/src/gcc_current/gcc/ipa-pure-const.c:1991
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug lto/88876] [9 regression] ICE in propagate_pure_const ipa-pure-const.c:1502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88876 --- Comment #1 from Dmitry G. Dyachenko --- $ /usr/local/gcc_current/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc_current/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-pc-linux-gnu Configured with: /home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --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=native Thread model: posix gcc version 9.0.0 20190116 (experimental) [trunk revision 267961] (GCC)
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 --- Comment #9 from Jakub Jelinek --- I've confirmed this started with r267953 (running under valgrind, otherwise it doesn't reproduce for me).
[Bug lto/88876] [9 regression] ICE in propagate_pure_const ipa-pure-const.c:1502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88876 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1
[Bug lto/88876] [9 regression] ICE in propagate_pure_const ipa-pure-const.c:1502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88876 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-16 Known to work||8.2.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #2 from Martin Liška --- Confirmed, started with my commit r261322.
[Bug target/88877] New: rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Bug ID: 88877
Summary: rs6000 emits signed extension for unsigned int
type(__floatunsidf).
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kamleshbhalui at gmail dot com
Target Milestone: ---
consider below testcase:
$cat test.c
void foo(){
unsigned int x=-1;
double d=x;
}
$./cc1 test.c -msoft-float -m64
$cat test.s
.foo:
.LFB0:
mflr 0
std 0,16(1)
stdu 1,-128(1)
.LCFI0:
li 9,-1
stw 9,112(1)
lwa 9,112(1)
mr 3,9
bl .__floatunsidf
nop
mr 9,3
std 9,120(1)
nop
addi 1,1,128
.LCFI1:
ld 0,16(1)
mtlr 0
blr
.long 0
.byte 0,0,0,1,128,0,0,1
Here, you can see that sign extension before calling the __floatunsidf routine.
As per my understanding it should emit zero extension here because
__floatunsidf has its argument as unsigned int type.
[Bug c++/88869] [7/8/9 Regression] ICE (Segmentation Fault) when using lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88869
--- Comment #3 from Jakub Jelinek ---
Note the auto return type on foo isn't important, it ICEs even with void foo ()
{ C ([] {}); }
The ICE is in
26858 tparms = DECL_TEMPLATE_PARMS (fn_tmpl);
26859 /* If type is a member class template, DECL_TI_ARGS (ctor) will
have
26860fully specialized args for the enclosing class. Strip those
off, as
26861the deduction guide won't have those template parameters. */
26862 targs = get_innermost_template_args (DECL_TI_ARGS (ctor),
26863 TMPL_PARMS_DEPTH
(tparms));
because tparms is NULL.
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |--- Summary|[7/8/9 Regression] Please |Please make |make|SANITIZER_NON_UNIQUE_TYPEIN |SANITIZER_NON_UNIQUE_TYPEIN |FO a runtime flag (or |FO a runtime flag (or |always true) |always true)| --- Comment #9 from Jakub Jelinek --- Why is this actually considered a regression? While in GCC 6 and older libsanitizer didn't have SANITIZER_NON_UNIQUE_TYPEINFO macro, it performed only == comparisons of the string pointers, so in the end it acted as if the current default of SANITIZER_NON_UNIQUE_TYPEINFO. Not suitable for libstdc++, sure, but not a regression. That said, I'm willing to ack it for GCC9 even then if upstream comes up with something or if they don't care, eventually as a GCC only tweak.
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 Martin Liška changed: What|Removed |Added Target Milestone|--- |9.0 --- Comment #10 from Martin Liška --- > That said, I'm willing to ack it for GCC9 even then if upstream comes up > with something or if they don't care, eventually as a GCC only tweak. Works for me. Note that so far there has been no reply to my patch.
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330 --- Comment #25 from Richard Biener --- When considering the patch from comment#18 additional data is that only 95802 out of 636160 disambiguations that ultimately require base_alias_check involve non-CONST_INT_P "other" operand. That is out of 9531871 total cases that would run into base_alias_check, or 1%. This is w/o "fixing" DSE (the simple patch of course miscompiles things).
[Bug libstdc++/86934] Feature test macros in should respect _GLIBCXX_HOSTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86934 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #1) > That should be simple, just include and and > compile with -Wsystem-headers to check for redefinition warnings. As discussed on IRC, for i in 98 11 14 17 2a; do echo '#include ' | g++ -D_GLIBCXX_VERSION_INCLUDED -E -std=c++$i -dD -xc++ - | grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]]*__cpp_' | sort -u > /tmp/1; echo '#include ' | g++ -E -std=c++$i -dD -xc++ - | grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]]*__cpp_' | sort -u > /tmp/2; diff -up /tmp/1 /tmp/2; done is a more thorough way of checking not just the case where both and other headers define the same __cpp_lib* macro differently, but also when one defines one and the other doesn't.
[Bug c++/88875] [9 regression] initializer_list and explicit ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875 --- Comment #2 from Nathan Sidwell --- That change looks suspicious in its own right -- it ends up mutating the initializer during the adding of overload candidates.
[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88861 --- Comment #5 from Segher Boessenkool --- Cool, thanks! Is the plan to simply not allow something that can throw to be recognised as noop move?
[Bug target/88682] new test case c-c++-common/pr51628-10.c fails starting with its introduction in r267313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88682 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Jan 16 14:18:47 2019 New Revision: 267970 URL: https://gcc.gnu.org/viewcvs?rev=267970&root=gcc&view=rev Log: PR c/51628 PR target/88682 * c-c++-common/pr51628-10.c (unaligned_int128_t): Add may_alias attribute. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr51628-10.c
[Bug c/51628] __attribute__((packed)) is unsafe in some cases (i.e. add -Waddress-of-packed-member, etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #60 from Jakub Jelinek --- Author: jakub Date: Wed Jan 16 14:18:47 2019 New Revision: 267970 URL: https://gcc.gnu.org/viewcvs?rev=267970&root=gcc&view=rev Log: PR c/51628 PR target/88682 * c-c++-common/pr51628-10.c (unaligned_int128_t): Add may_alias attribute. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr51628-10.c
[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86736
--- Comment #12 from Richard Biener ---
OK, so C++ has
else if ((DECL_NAME (decl) == NULL_TREE)
&& TREE_CODE (decl) == NAMESPACE_DECL)
dump_decl (cxx_pp, decl, TFF_PLAIN_IDENTIFIER | TFF_UNQUALIFIED_NAME);
and thus "copes" with namespaces without a name. I wonder if we want
pubnames late at all. For darwin and other targets with "crippled"
early LTO support (read: no support) this means we'd not generate those
lookup entries.
Since we output_pubtables only from dwarf2out_finish (why?) we don't
get those into early debug. Sth to investigate.
The ICE can probably be fixed with the following - can you test that?
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index a1b5a5eaf19..cd2e889a8cc 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -11074,7 +11074,9 @@ output_comp_unit (dw_die_ref die, int output_if_empty,
static inline bool
want_pubnames (void)
{
- if (debug_info_level <= DINFO_LEVEL_TERSE)
+ if (debug_info_level <= DINFO_LEVEL_TERSE
+ /* Names and types go to the early debug part only. */
+ || in_lto_p)
return false;
if (debug_generate_pub_sections != -1)
return debug_generate_pub_sections;
[Bug target/88682] new test case c-c++-common/pr51628-10.c fails starting with its introduction in r267313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88682 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c++/88875] [9 regression] initializer_list and explicit ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug target/88847] gcc.target/aarch64/sve/struct_move_1.c ICE with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88847 --- Comment #2 from Tamar Christina --- Using stack protector created an invalid addressing mode. It changes SP-64 into SP-80, presumably due to it storing the canary value. However 80 is not a multple of SVE_BYTE_MODE (32) so the instruction can't match. We probably need to insert some padding after the canary is stored?
[Bug target/70682] [9 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70682 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |10.0 --- Comment #6 from Jakub Jelinek --- Too late to do it for GCC9 as well. The workaround is still in.
[Bug debug/88878] New: .debug_pubnames/types empty with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878 Bug ID: 88878 Summary: .debug_pubnames/types empty with -flto Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Currently building with -g -gpubnames -flto will get you an empty .debug_pubnames section because dwarf2out_early_finish doesn't emit those into the early debug part (LTO section setup for pubnames is also missing). Since -gpubtypes is off by default on linux nobody noticed sofar.
[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88861 --- Comment #6 from David Malcolm --- (In reply to Segher Boessenkool from comment #5) > Cool, thanks! Is the plan to simply not allow something that can throw to be > recognised as noop move? Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00914.html (caveat: I'm relatively new to this code)
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 --- Comment #17 from Jakub Jelinek --- Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from the above committed change + fixing up ptrs_compare_unequal, or something equivalent like the VRP change) I'm afraid there isn't much possibilities left to do, and those changes are too risky for GCC9. The problem with your testcase is that NRV is in place, so we don't even know if s is an automatic variable or a global variable, or a heap variable etc.
[Bug rtl-optimization/88879] New: [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 Bug ID: 88879 Summary: [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Building SPEC 2000 on Itanium ICEs left and right in sel_target_adjust_priority.
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #1 from Richard Biener ---
Created attachment 45441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45441&action=edit
preprocessed source
/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/bin/gcc -c -o unlzw.o
-O3 unlzw.c -save-temps -v
Using built-in specs.
COLLECT_GCC=/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/bin/gcc
Target: ia64-unknown-linux-gnu
Configured with: /gcc/spec/sb-terbium-head-64/gcc/configure
--prefix=/gcc/spec/sb-terbium-head-64/ia64/install-201901161204
--enable-languages=c,c++,fortran --enable-threads=posix --disable-nls
--enable-__cxa_atexit --enable-clocale=gnu --enable-checking=release
--disable-libstdcxx-pch --disable-libsanitizer --disable-libcilkrts
--without-isl --disable-werror
Thread model: posix
gcc version 9.0.0 20190116 (experimental) [trunk revision 267969] (GCC)
COLLECT_GCC_OPTIONS='-c' '-o' 'unlzw.o' '-O3' '-save-temps' '-v'
/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/libexec/gcc/ia64-unknown-linux-gnu/9.0.0/cc1
-E -quiet -v unlzw.c -O3 -fpch-preprocess -o unlzw.i
ignoring nonexistent directory
"/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/lib/gcc/ia64-unknown-linux-gnu/9.0.0/../../../../ia64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/lib/gcc/ia64-unknown-linux-gnu/9.0.0/include
/usr/local/include
/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/include
/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/lib/gcc/ia64-unknown-linux-gnu/9.0.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-o' 'unlzw.o' '-O3' '-save-temps' '-v'
/gcc/spec/sb-terbium-head-64/ia64/install-201901161204/libexec/gcc/ia64-unknown-linux-gnu/9.0.0/cc1
-fpreprocessed unlzw.i -quiet -dumpbase unlzw.c -auxbase-strip unlzw.o -O3
-version -o unlzw.s
GNU C17 (GCC) version 9.0.0 20190116 (experimental) [trunk revision 267969]
(ia64-unknown-linux-gnu)
compiled by GNU C version 9.0.0 20190116 (experimental) [trunk revision
267969], GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2, isl
version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 9.0.0 20190116 (experimental) [trunk revision 267969]
(ia64-unknown-linux-gnu)
compiled by GNU C version 9.0.0 20190116 (experimental) [trunk revision
267969], GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2, isl
version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b841429784bb4c1bcbfd81a8b6b2b964
unlzw.c: In function 'unlzw':
unlzw.c:261:19: warning: implicit declaration of function 'spec_read'
[-Wimplicit-function-declaration]
261 | if ((rsize = read(in, (char*)inbuf+insize, INBUFSIZ)) == EOF) {
| ^
during RTL pass: mach
unlzw.c:377:1: internal compiler error: in sel_target_adjust_priority, at
sel-sched.c:3332
377 | }
| ^
0x40db257f sel_target_adjust_priority
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:3332
0x40db257f fill_vec_av_set
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:3726
0x40db34ff fill_ready_list
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:4027
0x40db34ff find_best_expr
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:4387
0x40db34ff fill_insns
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:5548
0x40dba63f schedule_on_fences
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:7364
0x40dba63f sel_sched_region_2
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:7502
0x40dbedff sel_sched_region_1
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:7544
0x40dc20ef sel_sched_region(int)
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:7645
0x40dc20ef sel_sched_region(int)
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:7630
0x40dc350f run_selective_scheduling()
/gcc/spec/sb-terbium-head-64/gcc/gcc/sel-sched.c:7731
0x41583aaf ia64_reorg
/gcc/spec/sb-terbium-head-64/gcc/gcc/config/ia64/ia64.c:9857
0x40d3274f execute
/gcc/spec/sb-terbium-head-64/gcc/gcc/reorg.c:3979
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 Richard Biener changed: What|Removed |Added Target||ia64 CC||amonakov at gcc dot gnu.org Target Milestone|--- |9.0
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #1 from Kamlesh Kumar ---
Following patch fixes the problem but would like to know the experts thought on
the below patch .
static machine_mode
-rs6000_promote_function_mode (const_tree type ATTRIBUTE_UNUSED,
+rs6000_promote_function_mode (const_tree type ,
machine_mode mode,
- int *punsignedp ATTRIBUTE_UNUSED,
+ int *punsignedp ,
const_tree, int)
{
+ if(type)
PROMOTE_MODE (mode, *punsignedp, type);
-
return mode;
}
Here, argument 'type' being null signifies that it's a libcalls.
So we will not promote the mode in this case,is that ok ?
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 --- Comment #2 from Richard Biener --- A little detail is that host GCC is GCC 4.1.2 which happened to miscompile GCC itself for quite a while (but now somehow we're back).
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-16 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- I can reproduce it with a cross from x86_64-linux.
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 Andrew Pinski changed: What|Removed |Added Keywords||ABI --- Comment #2 from Andrew Pinski --- Can you provide what the ABI says here? >From my memory it says it sign extended into 64bits but I could be wrong. I know the AARCH64 ABI says the top 32bits are undefined but that is not the powerpc64 ABI.
[Bug libstdc++/88859] [8/9 Regression] FAIL: experimental/string_view/operators/wchar_t/2.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88859 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24097 Resolution|--- |MOVED --- Comment #7 from H.J. Lu --- This is a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24097
[Bug c++/88865] [[no_unique_address]] leads to sizeof(T) == 0, which cannot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88865 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-16 Ever confirmed|0 |1
[Bug target/86891] [9 Regression] __builtin_sub_overflow incorrect for unsigned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891 --- Comment #11 from Richard Earnshaw --- Author: rearnsha Date: Wed Jan 16 15:18:05 2019 New Revision: 267971 URL: https://gcc.gnu.org/viewcvs?rev=267971&root=gcc&view=rev Log: __builtin__overflow issues on AArch64 (redux) Further investigation showed that my previous patch for this issue was still incomplete. The problem stemmed from what I suspect was a mis-understanding of the way overflow is calculated on aarch64 when values are subtracted (and hence in comparisons). In this case, unlike addition, the carry flag is /cleared/ if there is overflow (technically, underflow) and set when that does not happen. This patch clears up this issue by using CCmode for all subtractive operations (this can fully describe the normal overflow conditions without anything particularly fancy); clears up the way we express normal unsigned overflow using CC_Cmode (the result of a sum is less than one of the operands) and adds a new mode, CC_ADCmode to handle expressing overflow of an add-with-carry operation, where the standard idiom is no-longer sufficient to describe the overflow condition. PR target/86891 * config/aarch64/aarch64-modes.def: Add comment about how the carry bit is set by add and compare. (CC_ADC): New CC_MODE. * config/aarch64/aarch64.c (aarch64_select_cc_mode): Use variables to cache the code and mode of X. Adjust the shape of a CC_Cmode comparison. Add detection for CC_ADCmode. (aarch64_get_condition_code_1): Update code support for CC_Cmode. Add CC_ADCmode. * config/aarch64/aarch64.md (uaddv4): Use LTU with CCmode. (uaddvti4): Comparison result is in CC_ADCmode and the condition is GEU. (add3_compareC_cconly_imm): Delete. Merge into... (add3_compareC_cconly): ... this. Restructure the comparison to eliminate the need for zero-extending the operands. (add3_compareC_imm): Delete. Merge into ... (add3_compareC): ... this. Restructure the comparison to eliminate the need for zero-extending the operands. (add3_carryin): Use LTU for the overflow detection. (add3_carryinC): Use CC_ADCmode for the result of the carry out. Reexpress comparison for overflow. (add3_carryinC_zero): Update for change to add3_carryinC. (add3_carryinC): Likewise. (add3_carryinV): Use LTU for carry between partials. * config/aarch64/predicates.md (aarch64_carry_operation): Update handling of CC_Cmode and add CC_ADCmode. (aarch64_borrow_operation): Likewise. Modified: trunk/gcc/config/aarch64/aarch64-modes.def trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/predicates.md
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #3 from Umesh Kalappa --- https://members.openpowerfoundation.org/document/dl/576 it says we infer that, Map simple integer types (char, short, int, long, enum) to a single doubleword. Sign or zero extend values shorter than a doubleword to a doubleword based on whether the source data type is signed or unsigned.
[Bug rtl-optimization/88880] New: Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Bug ID: 0 Summary: Wrong code since r264897 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45442&action=edit test-case The test-case is isolated from OpenBLAS library. $ gcc /tmp/blast.c -g -O2 && ./a.out -9280:2.47 != 1.23 Aborted (core dumped)
[Bug libstdc++/88881] New: std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Bug ID: 1
Summary: std::filesystem::status gives bad results on mingw32
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
// { dg-options "-std=gnu++17" }
#include
#include
void print_status(std::filesystem::path p)
{
std::cout << p << " exists? " << std::boolalpha << exists(p) << '\n';
}
int main()
{
print_status("./");
print_status("./nonexistent-path/..");
print_status("./nonexistent-path/../");
}
This prints:
"./" exists? false
"./nonexistent-path/.." exists? true
"./nonexistent-path/../" exists? false
It seems that mingw's stat() fails for a directory with a trailing slash.
It also implicitly resolves .. components, without consideration for whether
the previous component exists or not (which seems consistent with DOS commands,
e.g. "cd .\kgjhfjfj\.." is equivalent to "cd .", but is not how stat is
supposed to work).
I'll report these to mingw32-w64 but will need to add workarounds to
std::filesystem.
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-1-16 CC||bergner at gcc dot gnu.org Known to work||8.2.0 Target Milestone|--- |9.0 Summary|Wrong code since r264897|[9 Regression] Wrong code ||since r264897 Known to fail||9.0
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Martin Liška changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug target/86891] [9 Regression] __builtin_sub_overflow incorrect for unsigned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891 --- Comment #12 from Richard Earnshaw --- Author: rearnsha Date: Wed Jan 16 15:22:08 2019 New Revision: 267972 URL: https://gcc.gnu.org/viewcvs?rev=267972&root=gcc&view=rev Log: __builtin__overflow issues on AArch64 (redux) (cont) And the ChangeLog for PR target/86891 fix. Modified: trunk/gcc/ChangeLog
[Bug debug/88882] New: gcc generates wrong debug information at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Bug ID: 2
Summary: gcc generates wrong debug information at -O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It incorrectly prints "l = 0" at -O1. CC'ing alex..
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20181224 (experimental) [trunk revision 267411] (GCC)
$ gdb-trunk -v
GNU gdb (GDB) 8.2.50.20181223-git
It prints "l = 2" without optimization.
$ gcc-trunk -g abc.c outer.c
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x40048e: file abc.c, line 9.
Breakpoint 1, main () at abc.c:9
9 optimize_me_not();
$1 = 2
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 11426) killed]
It incorrectly prints "l = 0" at -O1.
$ gcc-trunk -g abc.c outer.c -O1
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x400489: file abc.c, line 9.
Breakpoint 1, main () at abc.c:9
9 optimize_me_not();
$1 = 0
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 11440) killed]
$ cat abc.c
int a;
int b;
int c;
int main() {
for (; b;)
;
int l = 2;
for (; c < 2; c++)
optimize_me_not();
l = a;
}
$ cat outer.c
optimize_me_not() {}
$ cat cmds
b 9
r
p l
k
q
[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86736
--- Comment #13 from Iain Sandoe ---
(In reply to Richard Biener from comment #12)
> OK, so C++ has
>
> else if ((DECL_NAME (decl) == NULL_TREE)
>&& TREE_CODE (decl) == NAMESPACE_DECL)
> dump_decl (cxx_pp, decl, TFF_PLAIN_IDENTIFIER | TFF_UNQUALIFIED_NAME);
>
> and thus "copes" with namespaces without a name. I wonder if we want
> pubnames late at all. For darwin and other targets with "crippled"
> early LTO support (read: no support)
FWIW, I've implemented the GCC part of the support (it needs a bit of tidying
for posting, but [probably] not a stage #4 thing). Also discussed the required
support in dsymutil with one of the devs (there seems no objection to doing
this, in principle)... so it's "when" rather than "if".
... progress on new features and enhancements for Darwin will go quicker if we
can squish the codegen and testsuite bugs (which is where the effort is going
at present) ;)
> this means we'd not generate those lookup entries.
>
> Since we output_pubtables only from dwarf2out_finish (why?) we don't
> get those into early debug. Sth to investigate.
my (limited) understanding of the purpose is to improve startup time for debug
sessions, so possibly relevant outside of darwin?
> The ICE can probably be fixed with the following - can you test that?
yes, that fixes it (only tested c++ asan).
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index a1b5a5eaf19..cd2e889a8cc 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -11074,7 +11074,9 @@ output_comp_unit (dw_die_ref die, int
> output_if_empty,
> static inline bool
> want_pubnames (void)
> {
> - if (debug_info_level <= DINFO_LEVEL_TERSE)
> + if (debug_info_level <= DINFO_LEVEL_TERSE
> + /* Names and types go to the early debug part only. */
> + || in_lto_p)
> return false;
>if (debug_generate_pub_sections != -1)
> return debug_generate_pub_sections;
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #1 from Andrew Pinski --- That inline asm looks big and suspicious.
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 --- Comment #4 from Bill Schmidt --- "Values shorter than 32 bits are sign-extended or zero-extended, depending on whether they are signed or unsigned." Source: https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf, p.33. The same is true of the 64-bit ABIs, both ELFv1 and ELFv2.
[Bug driver/88883] New: [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 Bug ID: 3 Summary: [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: x86_64-w64-mingw32 Target: aarch64-none-elf Build: x86_64-linux-gnu Hi. It appears that when trying to build an x86_64-w64-mingw32 cross compiler targetting AArch64 the build fails at generated `gcc/options-save.c' due to narrowing conversion (using the latest trunk). This has likely something to do with the latest branch protection patches. The generated code looks like this (generated by `gcc/optc-save-gen.awk'): if (ptr->x_aarch64_branch_protection_string) fprintf (file, "%*s%s (%#lx)\n", indent, "", "aarch64_branch_protection_string", (unsigned long)ptr->x_aarch64_branch_protection_string); And this will cause something like: options-save.c::mm: error: cast from 'const char*' to 'long unsigned int' loses precision [-fpermissive] (unsigned long)ptr->x_aarch64_branch_protection_string); I'm not sure who is the real culprit here. Should the generated options saving code handle narrowing conversions better, or, as the above cast is only done for any option that does not fall under char, short, int, enum or /string/ types is this caused by a mishap when selecting the proper type for aarch64_branch_protection_string (at aarch64.opt)?
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #2 from Andrew Pinski --- The inline asm modifies the 0th and 1st operands. I think the inline asm is broken .
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #5 from Bill Schmidt --- So technically, if the target is 32-bit powerpc, the ABI is silent on the upper 32 bits. That's not necessarily a reasonable position to stand on, but when targeting powerpc (not powerpc64*) those bits are meaningless.
[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214 --- Comment #11 from Martin Jambor --- Author: jamborm Date: Wed Jan 16 15:37:33 2019 New Revision: 267974 URL: https://gcc.gnu.org/viewcvs?rev=267974&root=gcc&view=rev Log: [PR 88214] Check that an argument is a pointer 2019-01-16 Martin Jambor Backported from mainline 2018-12-10 Martin Jambor PR ipa/88214 * ipa-prop.c (determine_locally_known_aggregate_parts): Make sure we check pointers against pointers. testsuite/ * gcc.dg/ipa/pr88214.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/ipa/pr88214.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/ipa-prop.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #4 from Marek Polacek ---
There can be three scenarios:
1) decltype is in a template and it has no dependent expressions -- PROBLEM
- we call finish_compound_literal from cp_parser_functional_cast
- processing_template_decl is 1, so we just return compound_literal; without
calling check_narrowing
- then we call finish_decltype_type, EXPR is {NON_LVALUE_EXPR <2.0e+0>} but
that is not instantiation_dependent_uneval_expression_p, so we just take its
unlowered_expr_type and return it, without calling check_narrowing.
2) decltype is in a template and has dependent expressions
- we call finish_compound_literal from cp_parser_functional_cast
- processing_template_decl is 1, so we just return compound_literal; without
calling check_narrowing
- then we call finish_decltype_type, EXPR is
instantiation_dependent_uneval_expression_p, so we create DECLTYPE_TYPE with
the dependent expression
- tsubst_copy_and_build then calls
RETURN (finish_compound_literal (type, r, complain, cl));
while substituting the CONSTRUCTOR. Now processing_template_decl is 0, so
finish_compound_literal calls check_narrowing, so we detect it.
3) decltype is not in a template
- we call finish_compound_literal from cp_parser_functional_cast, but
processing_template_decl is 0, so we call check_narrowing so we detect it.
So one idea would to be to walk_tree on the expression at the end of
finish_decltype_type, looking for compound literals and call check_narrowing.
[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214 --- Comment #12 from Martin Jambor --- Author: jamborm Date: Wed Jan 16 15:41:07 2019 New Revision: 267975 URL: https://gcc.gnu.org/viewcvs?rev=267975&root=gcc&view=rev Log: [PR 88214] Check that an argument is a pointer 2019-01-16 Martin Jambor Backported from mainline 2018-12-10 Martin Jambor PR ipa/88214 * ipa-prop.c (determine_locally_known_aggregate_parts): Make sure we check pointers against pointers. testsuite/ * gcc.dg/ipa/pr88214.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/ipa/pr88214.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/ipa-prop.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815 --- Comment #5 from Marek Polacek --- (My proof-of-concept patch to deal with narrowing in decltype fixed this PR as a result.)
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #3 from Martin Liška --- (In reply to Andrew Pinski from comment #2) > The inline asm modifies the 0th and 1st operands. I think the inline asm is > broken . You are right, they are modified. Can you please help me how to fix the assembly (marking these 2 as output as well)?
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||law at redhat dot com Ever confirmed|0 |1
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 Alexander Monakov changed: What|Removed |Added CC||abel at gcc dot gnu.org --- Comment #4 from Alexander Monakov --- Thanks. This broke when the patch for PR 85458 was applied, and Andreas raised it on the gcc-patches thread: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00128.html Soon after that, the HP-PA adjust_priority target hook was removed, making the sel-sched change unnecessary. Therefore, my recommendation is to revert the sel-sched patch, or remove the new assert as Andreas has suggested. Andrey, which approach would you prefer? It's also possible to implement Jeff's suggestion and clamp negative priorities to zero in create_speculation_check, but that may turn out to be insufficient if there is other code producing negative priority values.
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #5 from David Malcolm ---
Created attachment 45443
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45443&action=edit
Reduced test case
This ICEs with -O3 at the same place.
3332 gcc_assert (new_priority >= 0);
where:
3321static int
3322sel_target_adjust_priority (expr_t expr)
3323{
3324 int priority = EXPR_PRIORITY (expr);
3325 int new_priority;
3326
3327 if (targetm.sched.adjust_priority)
3328new_priority = targetm.sched.adjust_priority (EXPR_INSN_RTX (expr),
priority);
3329 else
3330new_priority = priority;
3331
3332 gcc_assert (new_priority >= 0);
(gdb) p expr->priority
$7 = -1
(gdb) p new_priority
$8 = -1
(gdb) (gdb) p targetm.sched.adjust_priority
Undefined command: "". Try "help".
(gdb) p targetm.sched.adjust_priority
$9 = (int (*)(rtx_insn *, int)) 0x0
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #4 from Andrew Pinski --- Replace: : : "r" (i), "r" (n), With: : "+r" (i), "+r" (n), :
[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #6 from Marek Polacek ---
And of course r265789 changed int{(p(), 0U)} from being dependent to being
non-dependent, so scenario 2) to scenario 1).
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 --- Comment #11 from Rafael Avila de Espindola --- (In reply to Martin Liška from comment #10) > > That said, I'm willing to ack it for GCC9 even then if upstream comes up > > with something or if they don't care, eventually as a GCC only tweak. > > Works for me. Note that so far there has been no reply to my patch. You might want to CC: Filipe Cabecinhas
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Liška --- (In reply to Andrew Pinski from comment #4) > Replace: > : > : > "r" (i), >"r" (n), > > With: > : > "+r" (i), >"+r" (n), > : I can confirm it works, thus it's failure in the package. Let me report that.
[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Wed Jan 16 15:58:34 2019 New Revision: 267976 URL: https://gcc.gnu.org/viewcvs?rev=267976&root=gcc&view=rev Log: PR c++/78244 - narrowing conversion in template not detected. * call.c (perform_implicit_conversion_flags): Set IMPLICIT_CONV_EXPR_BRACED_INIT. * cp-tree.h (IMPLICIT_CONV_EXPR_BRACED_INIT): New. * pt.c (tsubst_copy_and_build): Use it. * g++.dg/cpp0x/Wnarrowing13.C: New test. * g++.dg/cpp0x/Wnarrowing14.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing13.C trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #6 from Martin Liška --- Upstream bug: https://github.com/xianyi/OpenBLAS/issues/1964
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 --- Comment #6 from Segher Boessenkool --- Sure, with 32-bit ABIs the registers are just 32 bits, for all intents and purposes. But we have -m64 here. (see also the "lwa" insn). I think that because __floatunsidf has no prototype all its args are taken to be int?
[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #7 from Jeffrey A. Law ---
Note that "dcmtk" in Fedora may be tripping over this as well. I haven't
looked in detail at it yet...
BUILDSTDERR: In file included from
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/include/dcmtk/ofstd/variadic/variant.h:19,
BUILDSTDERR: from
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/include/dcmtk/ofstd/ofvriant.h:379,
BUILDSTDERR: from
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/tests/tvariant.cc:26:
BUILDSTDERR:
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/include/dcmtk/ofstd/variadic/helpers.h:57:32:
error: narrowing conversion of '-1' from 'int' to 'long unsigned int'
[-Wnarrowing]
BUILDSTDERR:57 | : OFintegral_constant {};
BUILDSTDERR: |^
BUILDSTDERR: make[2]: ***
[ofstd/tests/CMakeFiles/ofstd_tests.dir/build.make:352:
ofstd/tests/CMakeFiles/ofstd_tests.dir/tvariant.cc.o] Error 1
BUILDSTDERR: make[2]: *** Waiting for unfinished jobs
Not exactly enough information to determine from the log file...
[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849 --- Comment #9 from Steve Kargl --- On Wed, Jan 16, 2019 at 07:13:37AM +, juergen.reuter at desy dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849 > > --- Comment #8 from Jürgen Reuter --- > I think this fix or something very near by causes an ICE in our code, I will > provide a bug report soon. > That's a bummer.
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 Tomáš Trnka changed: What|Removed |Added CC||trnka at scm dot com --- Comment #12 from Tomáš Trnka --- (In reply to Wilco from comment #11) > I'm not sure it's the same problem but the huge size increases I noticed are > due to not optimizing zeroes from initializers, so we end up with huge > rodata with only zeroes in it. It indeed is the same problem. The change in r254427 causes def_init to be generated for all types in a module (even if there's nothing to initialize), so any type with a large array in it will end up taking lots of space in rodata. Example: module FooModule type Foo integer :: array(100) end type end module program def_init_size use FooModule type(Foo) :: x x%array(1) = 1 write(*,*) x%array(1) end program VM SIZEFILE SIZE -- -- 50.0% 3.81Mi .rodata 3.81Mi 99.6% 100.0% 3.81Mi __foomodule_MOD___def_init_foomodule_Foo 3.81Mi 100.0% 0.0% 60 [section .rodata] 60 0.0% 0.0% 48 __foomodule_MOD___vtab_foomodule_Foo 48 0.0% 0.0% 28 options.1.357128 0.0% 0.0% 4 _IO_stdin_used 4 0.0% 50.0% 3.81Mi .bss 0 0.0% 100.0% 3.81Mi x.3565 0 NAN% 0.0% 31 [section .bss] 0 NAN% 0.0% 1 completed.7132 0 NAN%
