[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 --- Comment #15 from Richard Biener --- Author: rguenth Date: Tue Jul 2 07:35:23 2019 New Revision: 272922 URL: https://gcc.gnu.org/viewcvs?rev=272922&root=gcc&view=rev Log: 2019-07-02 Richard Biener PR tree-optimization/58483 * tree-ssa-scopedtables.c (avail_expr_hash): Use OEP_ADDRESS_OF for MEM_REF base hashing. (equal_mem_array_ref_p): Likewise for base comparison. * gcc.dg/tree-ssa/ssa-dom-cse-8.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-scopedtables.c
[Bug target/91052] New: [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052 Bug ID: 91052 Summary: [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, ra Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu gfortran-10.0.0-alpha20190630 snapshot (r272835) ICEs when compiling gcc/testsuite/gfortran.dg/vect/cost-model-pr34445.f w/ -misel -O2 (-O3, -Ofast) -fstack-protector -funroll-all-loops -fno-sched-pressure -fno-tree-ch -fno-tree-forwprop -fno-tree-ter: % powerpc-e300c3-linux-gnu-gfortran-10.0.0-alpha20190630 -misel -O2 -fstack-protector -funroll-all-loops -fno-sched-pressure -fno-tree-ch -fno-tree-forwprop -fno-tree-ter -c gcc/testsuite/gfortran.dg/vect/cost-model-pr34445.f during RTL pass: ira gcc/testsuite/gfortran.dg/vect/cost-model-pr34445.f:8:0: 8 | End | internal compiler error: in fix_reg_equiv_init, at ira.c:2705 0xbb050a fix_reg_equiv_init /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/ira.c:2704 0xbb050a fix_reg_equiv_init /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/ira.c:2684 0xbb2361 find_moveable_pseudos /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/ira.c:4868 0xbb9a84 ira /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/ira.c:5337 0xbb9a84 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/ira.c:5663
[Bug c++/91051] [9/10 Regression] Templated conversion operator to rvalue reference to constant don't match when converting to lvalue reference to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91051 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |9.2 Summary|[9 Regression] Templated|[9/10 Regression] Templated |conversion operator to |conversion operator to |rvalue reference to |rvalue reference to |constant don't match when |constant don't match when |converting to lvalue|converting to lvalue |reference to constant |reference to constant
[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052 Richard Biener changed: What|Removed |Added Keywords||needs-bisection CC||rsandifo at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #1 from Richard Biener --- Not sure if recent, just CCing suspect ;) Needs bisection anyways.
[Bug target/91043] GCC produces unaligned vmovdqa vector data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #21 from Richard Biener ---
(In reply to Hanoch Haim from comment #19)
> After some investigation, I think it is not a gcc issue, please verify.
> One of the internal object does not include a 64B alignment.
>
> #define __rte_cache_aligned __attribute__((__aligned__(64)));
>
> class CTimeHistogram {
>
> } __rte_cache_aligned;
>
>
> class CCPortLatency {
> public:
> CTimeHistogram m_hist;
> } __rte_cache_aligned; <<= without this, it is not aligned while the code
> generation assumed it is aligned !
>
> class Root {
>
> CCPortLatency port;
>
> } __rte_cache_aligned;
>
>
> Is it valid? why the code generation assumed the CCPortLatency is aligned
> because one of its internal is aligned?
Of course it does, because without aligning the container you cannot have
aligned members. Maximum alignment always propagates outwards.
[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #21 from Paul Thomas --- (In reply to pthaugen from comment #20) > (In reply to Segher Boessenkool from comment #17) > > sched2 swaps the two insns (37 and 40 for me -- use -dp to see the numbers > > in your .s file, use -da if you want lots of dumps, -dap together). > > > > So why did sched2 decide it can swap these? They are in the same aliasing > > set, so it shouldn't do this. Hrm. > > I'm looking into this... Hi there, Have you made any progress? Anyway, thanks for anything that you can do. Regards Paul
[Bug libgcc/91053] New: __builtin___clear_cache can fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91053 Bug ID: 91053 Summary: __builtin___clear_cache can fail Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: oth+gccbugs at google dot com Target Milestone: --- This issue arises from using libgcc in the Android Runtime's Just-In-Time compiler. The Android Runtime uses __buitin__clear_cache() for JIT cache maintenance and we’ve become aware that this builtin can silently fail. This leaves the CPU caches in an unknown state potentially leading to a crash from the execution of unintended instruction sequences. The specific case where we've observed this failure is for devices with ARMv7 Linux kernels. The libgcc clear_cache builtin calls the cacheflush() system call which bottoms out in v7_coherent_user_range(): https://github.com/torvalds/linux/blob/master/arch/arm/mm/cache-v7.S#L253 The important detail in that code is that the blocks of code within USER() macros will call the fault handler, labelled 9001, if the cache operation causes a fault. The return value from v7_coherent_user_range is then -EFAULT. When this happens after code updates in the JIT cache, crashes can be expected. For example, if we didn't manage to invalidate all of the instruction cache range, and thus executes a mix-and-match of old and new instructions. This issue is quite hard to reproduce and typically only occurs under memory pressure. The documentation for __builtin___clear_cache() does not comment on the possibilities of failures: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html but this is documented behaviour of the cacheflush() system call: http://man7.org/linux/man-pages/man2/cacheflush.2.html Potential fixes could include: 1) no change to __builtin__clear_cache, but update the documentation to indicate that failure is possible on systems where cache flushing is a privileged operation. On these systems callers of the builtin should clear errno before the call and check it afterwards. 2) change __builtin___clear_cache() to return an error code. 3) a fix for Linux kernels so cacheflush() cannot fail. [Outside the scope of this bug.] Our workaround for now is to special case on ARMv7 to use the cacheflush() system call directly and check for errors (http://r.android.com/989545).
[Bug c++/91054] New: replace __gnu_cxx::__normal_iterator by C::iterator in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91054
Bug ID: 91054
Summary: replace __gnu_cxx::__normal_iterator by
C::iterator in diagnostics
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Libstdc++ uses the __gnu_cxx::__normal_iterator class type for std::vector and
std::basic_string iterators, but it obfuscates diagnostics.
It would be much nicer to automatically replace the type's real name with the
public typedef that users are familiar with.
For this invalid program:
#include
int main()
{
std::vector v;
auto iter1 = v.begin();
auto iter2 = v.crbegin();
std::distance(iter1, iter2);
}
G++ prints:
iter.cc: In function 'int main()':
iter.cc:7:29: error: no matching function for call to
'distance(__gnu_cxx::__normal_iterator >&,
std::reverse_iterator<__gnu_cxx::__normal_iterator
> >&)'
7 | std::distance(iter1, iter2);
| ^
In file included from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_algobase.h:66,
from /home/jwakely/gcc/10/include/c++/10.0.0/vector:60,
from iter.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_iterator_base_funcs.h:138:5:
note: candidate: 'template typename
std::iterator_traits<_Iterator>::difference_type std::distance(_InputIterator,
_InputIterator)'
138 | distance(_InputIterator __first, _InputIterator __last)
| ^~~~
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_iterator_base_funcs.h:138:5:
note: template argument deduction/substitution failed:
iter.cc:7:29: note: deduced conflicting types for parameter '_InputIterator'
('__gnu_cxx::__normal_iterator >' and
'std::reverse_iterator<__gnu_cxx::__normal_iterator > >')
7 | std::distance(iter1, iter2);
| ^
I think this is easier to read as:
iter.cc: In function 'int main()':
iter.cc:7:29: error: no matching function for call to
'distance(std::vector::iterator&,
std::reverse_iterator::const_iterator >&)'
7 | std::distance(iter1, iter2);
| ^
In file included from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_algobase.h:66,
from /home/jwakely/gcc/10/include/c++/10.0.0/vector:60,
from iter.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_iterator_base_funcs.h:138:5:
note: candidate: 'template typename
std::iterator_traits<_Iterator>::difference_type std::distance(_InputIterator,
_InputIterator)'
138 | distance(_InputIterator __first, _InputIterator __last)
| ^~~~
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_iterator_base_funcs.h:138:5:
note: template argument deduction/substitution failed:
iter.cc:7:29: note: deduced conflicting types for parameter '_InputIterator'
('std::vector::iterator' and
'std::reverse_iterator::const_iterator >')
7 | std::distance(iter1, iter2);
| ^
This is the result of two simplifications:
Replace __gnu_cxx::__normal_iterator with C::const_iterator
and replace __gnu_cxx::__normal_iterator with C::iterator.
As a further step we could consider replacing
std::reverse_iterator with std::C::reverse_iterator, and
replacing std::reverse_iterator with
std::C::const_reverse_iterator. That's more questionable, because it's possible
that the user code actually does spell out
std::reverse_iterator rather than using the
C::reverse_iterator typedef.
For the __gnu_cxx::__normal_iterator case users should never be referring to
that type, they should only use the public and portable C::iterator and
C::const_iterator typedefs.
[Bug libgcc/91053] __builtin___clear_cache can fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91053 --- Comment #1 from Andrew Pinski --- So was reading the code. The only time a fault will happen when a page is not mapped in. This happens if the page was paged out (this is why it happens under heavily pressure). This is not about being privileged at all.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #24 from The Written Word --- (In reply to EML from comment #22) > Thanks for the hints and options > > on IA64, I used the GNU AS (2.32), but the HP LD (ld: 92453-07 linker ld HP > Itanium(R) B.12.65 IPF/IPF) Do you have this patch applied as you're using binutils 2.32? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338?
[Bug target/91043] GCC produces unaligned vmovdqa vector data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #22 from Hanoch Haim ---
"Of course it does, because without aligning the container you cannot have
aligned members. Maximum alignment always propagates outwards."
Sorry, your answer is still not clear, so let give a short example
In this case there is a discrepancy betwean two gcc modules
1. The module that generates the code think that it is aligned (CCPortLatency)
2. However the linker puts it in a none aligned location
"
class CTimeHistogram {
} __rte_cache_aligned;
class CCPortLatency {
public:
CTimeHistogram m_hist;
};
class Root {
CCPortLatency port;
} __rte_cache_aligned;
static Root root;
"
In this case can I expect root.port to be aligned because its child (m_hist)
was defined as aligned and it propogate? Or should I explicitly ask both to be
aligned?
[Bug target/91043] GCC produces unaligned vmovdqa vector data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #23 from Richard Biener ---
(In reply to Hanoch Haim from comment #22)
>
> "Of course it does, because without aligning the container you cannot have
> aligned members. Maximum alignment always propagates outwards."
>
> Sorry, your answer is still not clear, so let give a short example
> In this case there is a discrepancy betwean two gcc modules
>
> 1. The module that generates the code think that it is aligned
> (CCPortLatency)
> 2. However the linker puts it in a none aligned location
>
>
> "
> class CTimeHistogram {
>
> } __rte_cache_aligned;
>
> class CCPortLatency {
> public:
> CTimeHistogram m_hist;
> };
> class Root {
>
> CCPortLatency port;
>
> } __rte_cache_aligned;
>
> static Root root;
> "
>
> In this case can I expect root.port to be aligned because its child (m_hist)
> was defined as aligned and it propogate? Or should I explicitly ask both to
> be aligned?
Yes, for
class CTimeHistogram {
} __attribute__((aligned(64)));
class CCPortLatency {
public:
CTimeHistogram m_hist;
};
class Root {
CCPortLatency port;
};
static Root root;
'root' will be aligned to 64 bytes. This is also what you can easily
observe when inspecting the ELF object:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
...
[ 3] .bss NOBITS 0040
0040 WA 0 0 64
Symbol table '.symtab' contains 8 entries:
Num:Value Size TypeBind Vis Ndx Name
...
5: 64 OBJECT LOCAL DEFAULT3 _ZL4root
compiled without optimization since root is unused and will otherwise
be eliminated.
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 --- Comment #10 from Martin Jambor --- Created attachment 46544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46544&action=edit WIP patch I have written another patch that removes the edges from the vector at the time speculation is resolved rather than preventing creation of the edges in the first place. Unfortunately, the patch still trips over the added assert when LTO bootstrapping D. So we'll have to look into it and find out where the edges get deleted other than in check_speculations before figuring out whether this is the right approach or not.
[Bug target/91043] GCC produces unaligned vmovdqa vector data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #24 from Richard Biener ---
(In reply to Richard Biener from comment #23)
> (In reply to Hanoch Haim from comment #22)
> >
> > "Of course it does, because without aligning the container you cannot have
> > aligned members. Maximum alignment always propagates outwards."
> >
> > Sorry, your answer is still not clear, so let give a short example
> > In this case there is a discrepancy betwean two gcc modules
> >
> > 1. The module that generates the code think that it is aligned
> > (CCPortLatency)
> > 2. However the linker puts it in a none aligned location
> >
> >
> > "
> > class CTimeHistogram {
> >
> > } __rte_cache_aligned;
> >
> > class CCPortLatency {
> > public:
> > CTimeHistogram m_hist;
> > };
> > class Root {
> >
> > CCPortLatency port;
> >
> > } __rte_cache_aligned;
> >
> > static Root root;
> > "
> >
> > In this case can I expect root.port to be aligned because its child (m_hist)
> > was defined as aligned and it propogate? Or should I explicitly ask both to
> > be aligned?
>
> Yes, for
>
> class CTimeHistogram {
> } __attribute__((aligned(64)));
> class CCPortLatency {
> public:
> CTimeHistogram m_hist;
> };
> class Root {
> CCPortLatency port;
> };
> static Root root;
>
> 'root' will be aligned to 64 bytes. This is also what you can easily
> observe when inspecting the ELF object:
>
> Section Headers:
> [Nr] Name Type Address Offset
>Size EntSize Flags Link Info Align
> ...
> [ 3] .bss NOBITS 0040
>0040 WA 0 0 64
>
> Symbol table '.symtab' contains 8 entries:
>Num:Value Size TypeBind Vis Ndx Name
> ...
> 5: 64 OBJECT LOCAL DEFAULT3 _ZL4root
>
> compiled without optimization since root is unused and will otherwise
> be eliminated.
You can also check with
static_assert (__alignof__(root.port.m_hist) == 64, "oops");
(need to make port public for this, eh)
[Bug c++/91055] New: alignof () evaluated before layout is complete?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91055
Bug ID: 91055
Summary: alignof () evaluated before layout is complete?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For the following testcase the first static_assert fails but clang++ behavior
suggests applying alignof to a member that is still being defined is invalid.
struct T {
char c __attribute__((aligned(64)));
};
struct U {
T t;
static_assert (alignof (t) == 64, "oops");
};
static_assert (alignof (U::t) == 64, "oops");
The following silently generates wrong code, instantiating X<0> instead of
X<64>.
struct T {
char c __attribute__((aligned(64)));
};
template struct X {};
struct U {
T t;
X x;
};
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #25 from Thomas Koenig --- (In reply to Jerry DeLisle from comment #24) > On a different Ryzen machine: > > $ ./run.sh > 1024 3.2604169845581055 > 2048 2.7804551124572754 > 4096 2.6416599750518799 > 8192 2.5986809730529785 > 16384 2.5525100231170654 > 32768 2.5145640373229980 > 65536 9.2993371486663818 > 131072 9.0313489437103271 Oops. That increase for 65536 might be an L1 cache effect. Note: We are measuring only transfer speed to cache here. Transfer to actual hard disks will be much slower. It is still relevant though, especially since for the usual cycle of repeatedly calculating and writing data. The OS can then sync the data to disc at its leisure while the next calculation is running. So, what would be a good strategy to select a block size?
[Bug c++/91055] alignof () evaluated before layout is complete?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91055 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-02 Ever confirmed|0 |1
[Bug c++/91056] New: Fail: asan reports stack-use-after-scope in valid program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91056
Bug ID: 91056
Summary: Fail: asan reports stack-use-after-scope in valid
program
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: grishalipenko at protonmail dot com
Target Milestone: ---
#include
#include
class A
{
public:
A ()
{
g = std::make_unique (2.0);
}
private:
std::unique_ptr g;
std::vector v = {1, 2, 3, 4};
};
int main (/*int argc, char *argv[]*/)
{
for (int i = 0; i < 2; i++)
auto a = std::make_unique ();
return 0;
}
grigorij.lipenko@WS236 ~ $ g++ -g prog.cpp -Wall -Wextra -std=c++17
-fsanitize=address
grigorij.lipenko@WS236 ~ $ ./a.out
=
==41033==ERROR: AddressSanitizer: stack-use-after-scope on address
0x00200da0 at pc 0x7fe16ee380b0 bp 0x7ffe398abce0 sp 0x7ffe398ab488
READ of size 16 at 0x00200da0 thread T0
#0 0x7fe16ee380af in memmove (/lib64/libasan.so.5+0xa10af)
#1 0x204fad in int* std::__copy_move::__copy_m(int const*, int const*, int*)
/usr/include/c++/9/bits/stl_algobase.h:386
#2 0x204f41 in int* std::__copy_move_a(int const*,
int const*, int*) /usr/include/c++/9/bits/stl_algobase.h:404
#3 0x204e64 in int* std::__copy_move_a2(int
const*, int const*, int*) /usr/include/c++/9/bits/stl_algobase.h:440
#4 0x204cc8 in int* std::copy(int const*, int const*,
int*) /usr/include/c++/9/bits/stl_algobase.h:474
#5 0x204bc2 in int* std::__uninitialized_copy::__uninit_copy(int const*, int const*, int*)
/usr/include/c++/9/bits/stl_uninitialized.h:101
#6 0x2049b2 in int* std::uninitialized_copy(int const*,
int const*, int*) /usr/include/c++/9/bits/stl_uninitialized.h:134
#7 0x204399 in int* std::__uninitialized_copy_a(int
const*, int const*, int*, std::allocator&)
/usr/include/c++/9/bits/stl_uninitialized.h:289
#8 0x203dcf in void std::vector
>::_M_range_initialize(int const*, int const*,
std::forward_iterator_tag) /usr/include/c++/9/bits/stl_vector.h:1582
#9 0x20362e in std::vector
>::vector(std::initializer_list, std::allocator const&)
/usr/include/c++/9/bits/stl_vector.h:626
#10 0x20332f in A::A() /home/grigorij.lipenko/prog.cpp:8
#11 0x203993 in std::_MakeUniq::__single_object std::make_unique()
/usr/include/c++/9/bits/unique_ptr.h:853
#12 0x20319f in main /home/grigorij.lipenko/prog.cpp:19
#13 0x7fe16e89bf32 in __libc_start_main (/lib64/libc.so.6+0x23f32)
#14 0x20302d in _start (/home/grigorij.lipenko/a.out+0x20302d)
0x00200da0 is located 0 bytes inside of global variable 'C.0' defined in
'prog.cpp:8:3' (0x200da0) of size 16
SUMMARY: AddressSanitizer: stack-use-after-scope (/lib64/libasan.so.5+0xa10af)
in memmove
Shadow bytes around the buggy address:
0x80038160: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
0x80038170: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
0x80038180: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x80038190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800381a0: 00 00 01 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
=>0x800381b0: 00 00 00 00[f8]f8 f9 f9 f9 f9 f9 f9 00 00 00 00
0x800381c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800381d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800381e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800381f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80038200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap: cc
==41033==ABORTING
Not reproduced with gcc 8.3.0 and clang 7.1.0
[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #16 from Andrew Roberts ---
That kicks a memory loose, from my build script:
# sed needed for GMP >=5.1 && < 6.2.0 on ARM otherwise isl build fails with
# undefined symbol __gmpn_invert_limb
sed -ixx "s/none-/${uname_m}-/" Makefile
Building natively on arm was failing using the host set to none-*-*.
none-*-* seems to work ok on Raspbian on the pi4. And it fails if you alter it,
although as I'm altering to uname -m, which gives armv7l, this would explain
some things. But not why a vanilla gcc-8.3.0 and 9.1.0 built with system gmp
can be used to rebuild themselves using the above sed and intree gmp.
However all my other arm machines (odroid-c2, odroid-xu4, rpi zero, rpi b, rpi
3b) all need this fix to build. They are running arch linux arm.
I'll recheck on the faster ones in the next few days, with both 8.3.0 and
9.1.0, to confirm if that is still the case.
[Bug libstdc++/91057] New: Data race in locale(const locale&, Facet*) constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91057
Bug ID: 91057
Summary: Data race in locale(const locale&, Facet*) constructor
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: karen.arutyunov at gmail dot com
Target Milestone: ---
In our build2 toolchain project we instantiate std::basic_regex class template
with a custom character type (line_char) that, in particular, requires
std::regex_traits specialization and defining a locale class that
installs the std::ctype facet in constructor.
Objects of the regex class that inherits from std::basic_regex are
created, used and destroyed concurrently in multiple threads but are not shared
between threads.
The problem is that while creating such an objects std::bad_cast is
sporadically thrown. Unfortunately, I'm unable to reproduce the issue in my
development environment to provide a full stack trace and, moreover, a simple
test to replicate the issue. However, debugging through the creation of these
regex objects makes me think that there is the following data race in the
libstdc++'s locale implementation that may case the described behavior.
The locale(const locale&, Facet*) constructor template (that is called from
multiple threads in our case) calls
_M_impl->_M_install_facet(&_Facet::id, __f);
that in turn calls _M_id() for the passed facet id. On the first call the
locale::id::_M_id() function sets/uses the locale::id::_M_index member in the
thread-unsafe manner:
size_t
locale::id::_M_id() const throw()
{
if (!_M_index)
{
_M_index = ...
}
return _M_index - 1;
}
As a result, 2 locale objects created concurrently in 2 threads with the
mentioned constructor may have a facet of the same type to be saved under
different indexes in the _M_facets array. If that happens then use_facet()
template function called for this facet type will end up badly for one of the
objects, taking the facet pointer from the wrong index (may crash, throw
bad_cast, etc).
[Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394 --- Comment #7 from Andrea Bocci --- The same test program will fail in the same way, if compiled with -flto, even if -pthread is used: $ g++-9 -Wall -Wextra -std=c++17 callonce.cpp -pthread $ ./a.out but $ g++-9 -Wall -Wextra -std=c++17 callonce.cpp -pthread -flto $ ./a.out terminate called after throwing an instance of 'std::system_error' what(): Unknown error -1 Aborted (core dumped) Possibly because the LTO pass discards the dependency on libpthread.so: $ ldd a.out linux-vdso.so.1 (0x7ffc09b46000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f420535e000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f4204f7e000) /lib64/ld-linux-x86-64.so.2 (0x7f4205952000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f4204be) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f42049c8000)
[Bug target/91043] GCC produces unaligned vmovdqa vector data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043 Hanoch Haim changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #25 from Hanoch Haim --- Hi Richard, You were right all along. I've looked into the wrong place! I understand it now and it is not a gcc issue. gcc7/8 are just better than gcc 6 with code generation. 1. The alignment is contagious, gcc marks all the parent objects of such an object as aligned. 2. With static allocated object there is no issue. 3. The issue in my case was a dynamic allocation of a different object that includes the aligned object. The object(parent) is assumed to be aligned, but was allocated dynamically (not aligned) Thank you for the explanation.
[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91057 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-02 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Looks like we want a compare-and-swap there.
[Bug libstdc++/78552] std::locale::classic() Needless Race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78552 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-02 Ever confirmed|0 |1
[Bug c++/91058] New: Crash involving std::variant, std::visit, templates, and static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91058
Bug ID: 91058
Summary: Crash involving std::variant, std::visit, templates,
and static constexpr
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom.smeding at gmail dot com
Target Milestone: ---
Created attachment 46545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46545&action=edit
Preprocessed output of the code using GCC 7.4.0
In GCC 7.4.0 in C++17 mode, the following code crashes the compiler with a
segmentation fault:
#include
class some_class
{
public:
void encode() const {}
};
// This template is necessary to trigger the bug.
template
void process() noexcept
{
// This variable needs to be both static and constexpr to trigger the
bug.
static constexpr some_class magic;
// The useless visit here is necessary to trigger the bug.
std::visit([](auto &&key) {
// This encode function must be a member function to trigger the
bug.
magic.encode();
}, std::variant{});
}
// Instantiate the template above
template void process() noexcept;
In particular, if the attachment is called a.cpp and 'g++' refers to the C++
frontend of GCC 7.4.0, the following command crashes:
g++ -std=c++17 a.cpp
The compiler output is as follows:
a.cpp: In instantiation of ‘process():: [with auto:1 = int;
encoder_t = int]’:
/usr/include/c++/7/variant:1252:44: required from ‘constexpr decltype(auto)
std::visit(_Visitor&&, _Variants&& ...) [with _Visitor = process() [with
encoder_t = int]::; _Variants = {std::variant}]’
a.cpp:16:15: required from ‘void process() [with encoder_t = int]’
a.cpp:23:30: required from here
a.cpp:18:21: internal compiler error: Segmentation fault
magic.encode();
^~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Platform: stock Ubuntu 18.04.2
'g++ -v' output:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
[Bug c++/91058] Crash involving std::variant, std::visit, templates, and static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91058 Tom Smeding changed: What|Removed |Added CC||tom.smeding at gmail dot com --- Comment #1 from Tom Smeding --- Note about the above: I am aware that this works as expected on GCC 8.3.0. However, given that 7.4.0 is still supported and used as the default compiler on Ubuntu 18.04 (which is used by a lot of people), I considered this worth reporting.
[Bug middle-end/91059] New: [10 regression] gcc.c-torture/execute/builtins/snprintf-chk.c fails on aarch64-elf since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91059 Bug ID: 91059 Summary: [10 regression] gcc.c-torture/execute/builtins/snprintf-chk.c fails on aarch64-elf since r272843 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi, Since r272843, I've noticed a failure on aarch64-elf: FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects Note that: - the other compilation flags combinations still work - aarch64-linux does not have this regression (my aarch64-elf is using newlib) - there's the same regression on aarch64_be-elf - aarch64-elf still passes when forcing -mabi=ilp32
[Bug middle-end/91060] New: [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060 Bug ID: 91060 Summary: [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi, Since r272843 was committed, I have noticed a regression on armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16: FAIL: gcc.c-torture/execute/scal-to-vec1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gcc.c-torture/execute/scal-to-vec1.c -O3 -g execution test FAIL: gcc.c-torture/execute/scal-to-vec2.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gcc.c-torture/execute/scal-to-vec2.c -O3 -g execution test arm-none-linux-gnueabihf still passes (armeb stands for arm big-endian) I'm using qemu-3.1 as simulator.
[Bug c++/91058] Crash involving std::variant, std::visit, templates, and static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91058 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-02 Known to work||10.0, 8.1.0, 8.3.0, 9.1.0 Ever confirmed|0 |1 Known to fail||7.4.1 --- Comment #2 from Jonathan Wakely --- This was fixed for GCC 8 by r251433 "Reimplement handling of lambdas in templates." That was a very large patch and not appropriate to backport to gcc-7-branch. Given that C++17 support in GCC 7 (and 8) is experimental, I think this is not a priority to fix for the final GCC 7.x release.
[Bug c++/91058] Crash involving std::variant, std::visit, templates, and static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91058 Tom Smeding changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Tom Smeding --- Thanks for the clarification, and the very quick response Jonathan! - Tom
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736 Eric Gallager changed: What|Removed |Added CC||jg at jguk dot org --- Comment #9 from Eric Gallager --- This came up again on gcc-help here: https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html
[Bug tree-optimization/91033] [10 Regression] ICE in vect_analyze_loop, at tree-vect-loop.c:2416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91033 --- Comment #4 from Jakub Jelinek --- (In reply to Richard Biener from comment #3) > 08:57 < richi> jakub: can we delay scatter/gather store recog to >vectorizable_store/load, thus always detect the dataref > pattern >but only later decide if we can vectorize it? > 08:58 < richi> jakub: this way we could also decide, based on cost, to do >strided accesses / vector construction instead (might be >profitable for V2DF for example) Had a look at this, and I doubt it is possible, while the gather_scatter_info gs_info; if (!vect_check_gather_scatter (stmt_info, as_a (vinfo), &gs_info) || !get_vectype_for_scalar_type (TREE_TYPE (gs_info.offset))) return opt_result::failure_at (stmt_info->stmt, (gatherscatter == GATHER) ? "not vectorized: not suitable for gather load %G" : "not vectorized: not suitable for scatter store %G", stmt_info->stmt); hunk could be moved from vect_analyze_data_refs slightly later, I'm afraid we need it already in vect_mark_stmts_to_be_vectorized so that we can call process_use there. And that call is still in the fatal = true; area (furthermore, for SLP we don't really call that).
[Bug d/91061] New: Enum type libcall_type violates the C++ One Definition Rule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91061 Bug ID: 91061 Summary: Enum type libcall_type violates the C++ One Definition Rule Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: jamborm at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: x86_64-linux When LTO-bootstrapping GCC with the D language, I get the following warnings: /home/mjambor/gcc/mine/src/gcc/d/runtime.cc:37:6: warning: type ‘libcall_type’ violates the C++ One Definition Rule [-Wodr] /home/mjambor/gcc/mine/src/gcc/rtl.h:4112:6: note: an enum with different value name is defined in another tra nslation unit And a quick look confirms that is indeed the case. Of course, to truly confuse the linker/LTO, you'd probably need also two functions with the same name taking a parameter of that one shared name, but I suppose it would be better not to wait for that to happen and adhere to C++ rules anyway and rename one of the types. Steps to reproduce: Configure with --enable-languages=c,d,c++ and --with-build-config=bootstrap-lto Run make and then go through the output.
[Bug ipa/91062] New: gcc.dg/ipa/ipa-pta-1.c dump contains garbage when gcc was configured with --enable-checking=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91062 Bug ID: 91062 Summary: gcc.dg/ipa/ipa-pta-1.c dump contains garbage when gcc was configured with --enable-checking=all Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: GC Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: amylaar at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu (probably doesn't really matter) Target: native or cross A number of symbol names in the dump file have been replaced by what looks like ggc erased memory. The problem can be hidden by adding a suitable min_expand value, e.g. (for native unix): make check-gcc RUNTESTFLAGS='--target_board=unix/--param=ggc-min-expand=30 ipa.exp=ipa-pta-1.c' on a machine with 16 GB RAM + 8 GB swap. OTOH, I haven't been able to reproduce this using a compiler that hasn't been configured with --enable-checking, or merely with --enable-checking=yes, even when adding --param=ggc-min-expand=0 . We've originally observed this in a variant of gcc 8.2, so this bug has probably been around for a while.
[Bug tree-optimization/91033] [10 Regression] ICE in vect_analyze_loop, at tree-vect-loop.c:2416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91033 --- Comment #5 from Jakub Jelinek --- Created attachment 46546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46546&action=edit gcc10-pr91033.patch This works though.
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059
Moritz Bender changed:
What|Removed |Added
CC||molli.bender at gmail dot com
--- Comment #2 from Moritz Bender ---
I don't know whether this comment will ever be read, but I'd like to add that I
have the same problem with strncpy incorrectly getting the "warning: 'strncpy'
specified bound depends on the length of the source argument". I do believe
that this warning is wrong in the case that the destination buffer is also
dependant on the strlen of the source string.
Assume the following code:
char my_string[strlen(argv[1] - 1)];
strncpy(my_string, argv[1], strlen(argv[1]) - 5);
memcpy(&my_string[strlen(argv[1]) - 5], ".7z", 4);
printf("my string: %s\n", my_string);
This code will generate the mentioned warning, although I don't think it
should. I HAVE to use strlen to achieve what I want to; this is a relatively
common use case. I know I can use memcpy instead of the strncpy, but regarding
that her I'm just dealing with strings I'd rather use strncpy.
[Bug c/79632] params.def should not contain redundant comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79632 --- Comment #2 from Roland Illig --- (In reply to Eric Gallager from comment #1) > What exactly is the harm of the redundancy? I don't think this is too big of > an issue... The harm of redundancy is that there is no single point of truth. When there are two places in the code saying the same thing, it's one too much. And if they differ by a tiny bit, you cannot be sure which one is correct. The two places should always say the very same, or it gets confusing. Having redundant code is like saying what can be said in a single sentence, just that it takes more than five sentences. When the code says the same several times, it takes more time reading the code since you have to read the same sentence more than once. When the comment differs from the code, how can you say which one is the correct one? The harm of redundancy is that it costs more time to read the same sentence several times. The harm of redundancy is that it takes more time to read the same sentence twice or even more often. I hope I have made my point. :)
[Bug ipa/91062] gcc.dg/ipa/ipa-pta-1.c dump contains garbage when gcc was configured with --enable-checking=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91062 --- Comment #1 from Jorn Wolfgang Rennecke --- Similarly, gcc.dg/torture/ipa-pta-1.c fails four scan tests because ipa-pta-1.c.083i.pta2 gets corrupted in the ENABLE_GC_ALWAYS_COLLECT scenario.
[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #7 from ensadc at mailnesia dot com --- It seems that r260272 changed `build_conditional_expr_1` to not create lvalue-to-rvalue conversion for such conditional expressions, but failed to change `lvalue_kind` to treat such expressions as glvalue, so GCC still thinks they are prvalue (https://gcc.gnu.org/viewvc/gcc/trunk/gcc/cp/tree.c?view=markup#l303) and applies copy elision (and probably other weird things).
[Bug tree-optimization/91063] New: [10 Regression] ICE in set_vinfo_for_stmt, at tree-vectorizer.c:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91063 Bug ID: 91063 Summary: [10 Regression] ICE in set_vinfo_for_stmt, at tree-vectorizer.c:676 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-checking, ice-on-valid-code, openmp Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu Created attachment 46547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46547&action=edit Testcase g++-10.0.0-alpha20190630 snapshot (r272835) ICEs when compiling the attached testcase at any optimization level (except -Og) and w/ -std=c++17 -march=knl -fopenmp-simd: % x86_64-unknown-linux-gnu-g++-10.0.0-alpha20190630 -std=c++17 -march=knl -O1 -fopenmp-simd -c rq776ble.cc during GIMPLE pass: vect rq776ble.cc: In function 'void ip(BN) [with BN = b2::operator()(C8) [with C8 = void (*)()]::]': rq776ble.cc:19:1: internal compiler error: in set_vinfo_for_stmt, at tree-vectorizer.c:676 19 | ip (BN rl) | ^~ 0x7c9bf7 vec_info::set_vinfo_for_stmt(gimple*, _stmt_vec_info*) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vectorizer.c:676 0x11e2b98 vec_info::add_stmt(gimple*) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vectorizer.c:525 0x118e66d vect_finish_stmt_generation_1 /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vect-stmts.c:1760 0x1190975 vect_init_vector_1 /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vect-stmts.c:1407 0x1190bc8 vect_init_vector(_stmt_vec_info*, tree_node*, tree_node*, gimple_stmt_iterator*) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vect-stmts.c:1496 0x11a242c vectorizable_load /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vect-stmts.c:8640 0x11b06dc vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*, _slp_tree*, _slp_instance*) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vect-stmts.c:10672 0x11b1759 vect_transform_loop_stmt /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vect-loop.c:8458 0x11b673d vect_transform_loop(_loop_vec_info*) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vect-loop.c:8679 0x11e3978 try_vectorize_loop_1 /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vectorizer.c:982 0x11e43ef vectorize_loops() /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190630/work/gcc-10-20190630/gcc/tree-vectorizer.c:1114
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059 Martin Sebor changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed|2018-11-16 00:00:00 |2019-07-02 Blocks||83819 Resolution|WONTFIX |--- Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- The warning isn't wrong -- the strncpy bound does depend on the length of the source argument. But I agree that it isn't helpful. As I mentioned in comment #1 there may be a way to avoid it in a subset of instances but it requires some non-trivial changes. At a minimum these come to mind: 1) track the size of the memory allocated either by malloc or alloca/VLAs 2) look at the next statement to see if it appends the terminating nul without assuming the strncpy call itself appended it That said, (2) already exists, albeit to a limited extent, so it needs to be extended to other places. (1) would be useful for many other things (e.g., detection of heap buffer overflow or reading from uninitialized heap memory). It's something I'm already planning to work on in any case, so I'll see if I can deal with this as well. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 88059, which changed state. Bug 88059 Summary: Spurious stringop-overflow warning with strlen, malloc and strncpy https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059 What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|WONTFIX |---
[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 --- Comment #3 from qinzhao at gcc dot gnu.org --- Author: qinzhao Date: Tue Jul 2 20:23:30 2019 New Revision: 272948 URL: https://gcc.gnu.org/viewcvs?rev=272948&root=gcc&view=rev Log: PR preprocessor/90581 Add a cpp option -fmax-include-depth to set the maximum depth of the nested #include. Added: trunk/gcc/testsuite/c-c++-common/cpp/fmax-include-depth-1a.h trunk/gcc/testsuite/c-c++-common/cpp/fmax-include-depth-1b.h trunk/gcc/testsuite/c-c++-common/cpp/fmax-include-depth.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/doc/cppopts.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/include/cpplib.h trunk/libcpp/init.c trunk/libcpp/internal.h
[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 qinzhao at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot gnu.org --- Comment #4 from qinzhao at gcc dot gnu.org --- the patch has been committed into upstream as today.
[Bug c++/91064] New: __is_standard_layout incorrect for a class with multiple bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91064
Bug ID: 91064
Summary: __is_standard_layout incorrect for a class with
multiple bases
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
According to class.prop in N4800:
A class S is a standard-layout class if it:
...
(3.5) -- has at most one base class subobject of any given type
The test case below is taken from the example in paragraph 4 in that section.
The GCC traits reports that class U is standard layout, in violation of the
spec. (Clang does the same.)
$ cat x.C && gcc -S -Wall x.C
struct Q { };
struct S { };
struct T { };
struct U: S, T { }; // not a standard-layout class
static_assert (!__is_standard_layout (U));
x.C:6:16: error: static assertion failed
6 | static_assert (!__is_standard_layout (U));
|^
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736 --- Comment #10 from Jonny Grant --- Thank you for adding me to the ticket. I'll add a bounty of $150 for this feature. Could Prathamesh's change be incorporated? Thank you, Jonny
[Bug testsuite/91065] New: gcc.dg/plugin/start_unit_plugin.c uses ggc memory without registering a root_tab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91065 Bug ID: 91065 Summary: gcc.dg/plugin/start_unit_plugin.c uses ggc memory without registering a root_tab Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: GC Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: amylaar at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu (probably doesn't really matter) Target: native or cross gcc.dg/plugin/start_unit_plugin.c isets fake_var to ggc-allocated memory, without registering a root_tab that references fake_var. This causes gcc.dg/plugin/start_unit-test-1.c to fail when the compiler is configured with --enable-checking=all
[Bug testsuite/91065] gcc.dg/plugin/start_unit_plugin.c uses ggc memory without registering a root_tab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91065 Jorn Wolfgang Rennecke changed: What|Removed |Added Keywords||patch --- Comment #1 from Jorn Wolfgang Rennecke --- I've posted a patch: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00187.html
[Bug c++/91066] New: GCC does not provide XOP functions through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91066
Bug ID: 91066
Summary: GCC does not provide XOP functions through
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This is a tad bit unusual since we can use SSE2, SSE3, ..., AVX, AVX2 as
expected.
According to the GCC docs and -march=bdver1, the arch does enable XOP as
expected (https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/x86-Options.html).
However, the XOP functions are not available through either
(http://www.g-truc.net/post-0359.html) or
(https://docs.microsoft.com/en-us/cpp/intrinsics/x64-amd64-intrinsics-list?view=vs-2019).
bulldozer:cryptopp$ cd ..
bulldozer:~$ g++ -march=bdver1 -msse4.1 test.cxx
test.cxx: In function ‘int main(int, char**)’:
test.cxx:15:9: error: ‘_mm_roti_epi64’ was not declared in this scope
b = _mm_roti_epi64(a, 1);
^~
test.cxx:15:9: note: suggested alternative: ‘_mm_rorv_epi64’
b = _mm_roti_epi64(a, 1);
^~
_mm_rorv_epi64
bulldozer:~$ cat test.cxx
#ifdef __XOP__
#include
#include
#endif
#ifdef __SSE41__
#include
#endif
int main(int argc, char* argv[])
{
__m128i a=_mm_setzero_si128(), b=_mm_setzero_si128(), c;
#ifdef __XOP__
b = _mm_roti_epi64(a, 1);
#endif
#ifdef __SSE41__
c = _mm_blend_epi16(a, b, 0);
#endif
return 0;
}
And:
$ gcc --version
gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
$ lsb_release -a
Distributor ID: Fedora
Description:Fedora release 29 (Twenty Nine)
Release:29
Codename: TwentyNine
[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883 --- Comment #13 from Jeffrey A. Law --- Author: law Date: Tue Jul 2 23:01:53 2019 New Revision: 272949 URL: https://gcc.gnu.org/viewcvs?rev=272949&root=gcc&view=rev Log: PR tree-optimization/90883 * g++.dg/tree-ssa/pr90883.c: Add -Os. Check dse2 for the deleted store on some targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr90883.C
[Bug c++/91051] [9/10 Regression] Templated conversion operator to rvalue reference to constant don't match when converting to lvalue reference to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91051 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Changed in r269602.
[Bug ipa/91062] gcc.dg/ipa/ipa-pta-1.c dump contains garbage when gcc was configured with --enable-checking=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91062
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 from Jorn Wolfgang Rennecke ---
varmap is allocated on the heap, and lives across passes. Yes it references
a name that is sometimes in static storage, but mostly in ggc-allocated memory.
I suppose inhibiting garbage collection during ipa would be no good, so
either the names should be allocated on the heap (ironically, often the name is
generated on the heap and later copied to ggc memory), or be reachable from a
ggc root.
I have traced the output of one garbage string emitted in the dump file for
gcc.dg/torture/ipa-pta-1.c back to its origin (index is 9 in new_var_info,
and the string is in "name"; gcc source svn revision is 272931):
#0 new_var_info (t=0x0, name=0x7fffefba2050 "test4.clobber", add_id=false)
at ../../gcc/gcc/tree-ssa-structalias.c:383
#1 0x00fa2d81 in create_function_info_for (decl=0x7fffefce8700,
name=0x7fffefb9ff40 "test4", add_id=false, nonlocal_p=true)
at ../../gcc/gcc/tree-ssa-structalias.c:5785
#2 0x00fa9725 in ipa_pta_execute ()
at ../../gcc/gcc/tree-ssa-structalias.c:8095
#3 0x00faab71 in (anonymous namespace)::pass_ipa_pta::execute (
this=0x271a9e0) at ../../gcc/gcc/tree-ssa-structalias.c:8493
#4 0x00c5e991 in execute_one_pass (pass=pass@entry=0x271a9e0)
at ../../gcc/gcc/passes.c:2473
#5 0x00c5fa32 in execute_ipa_pass_list (pass=0x271a9e0)
at ../../gcc/gcc/passes.c:2913
#6 0x008918e9 in symbol_table::compile (
this=this@entry=0x7fffefb9e100) at ../../gcc/gcc/cgraphunit.c:2648
#7 0x00894b08 in symbol_table::compile (this=0x7fffefb9e100)
at ../../gcc/gcc/cgraphunit.c:2825
#8 symbol_table::finalize_compilation_unit (this=0x7fffefb9e100)
at ../../gcc/gcc/cgraphunit.c:2861
#9 0x00d8d544 in compile_file () at ../../gcc/gcc/toplev.c:481
#10 0x006b8919 in do_compile () at ../../gcc/gcc/toplev.c:2209
#11 toplev::main (this=this@entry=0x7fffddf0, argc=,
argc@entry=22, argv=, argv@entry=0x7fffdef8)
... at the end of the pass ...
#0 ggc_collect () at ../../gcc/gcc/ggc-page.c:2174
#1 0x00c5e6fb in execute_one_ipa_transform_pass (ipa_pass=0x271a2e0,
node=0x7fffefb9d708) at ../../gcc/gcc/passes.c:2232
#2 execute_all_ipa_transforms () at ../../gcc/gcc/passes.c:2250
#3 0x00882662 in cgraph_node::get_body (this=0x7fffefb9d708)
at ../../gcc/gcc/cgraph.c:3621
#4 0x00fa9633 in ipa_pta_execute ()
at ../../gcc/gcc/tree-ssa-structalias.c:8077
#5 0x00faab71 in (anonymous namespace)::pass_ipa_pta::execute (
this=0x271a9e0) at ../../gcc/gcc/tree-ssa-structalias.c:8493
#6 0x00c5e991 in execute_one_pass (pass=pass@entry=0x271a9e0)
at ../../gcc/gcc/passes.c:2473
#7 0x00c5fa32 in execute_ipa_pass_list (pass=0x271a9e0)
at ../../gcc/gcc/passes.c:2913
#8 0x008918e9 in symbol_table::compile (
this=this@entry=0x7fffefb9e100) at ../../gcc/gcc/cgraphunit.c:2648
#9 0x00894b08 in symbol_table::compile (this=0x7fffefb9e100)
at ../../gcc/gcc/cgraphunit.c:2825
#10 symbol_table::finalize_compilation_unit (this=0x7fffefb9e100)
at ../../gcc/gcc/cgraphunit.c:2861
#11 0x00d8d544 in compile_file () at ../../gcc/gcc/toplev.c:481
#12 0x006b8919 in do_compile () at ../../gcc/gcc/toplev.c:2209
#13 toplev::main (this=this@entry=0x7fffddf0, argc=,
... lots of garbage collections and constraint dumpings later...
#0 __GI__IO_fputs (str=0x7fffefba2050 '\245' , "\"",
fp=0x27fd8e0) at iofputs.c:32Breakpoint 8, dump_constraint (file=0x27fd8e0,
c=0x281fc38)
at ../../gcc/gcc/tree-ssa-structalias.c:678
678 fprintf (file, "%s", get_varinfo (c->lhs.var)->name);
(gdb) s
get_varinfo (n=9) at ../../gcc/gcc/tree-ssa-structalias.c:346
346 return varmap[n];
(gdb) fin
Run till exit from #0 get_varinfo (n=9)
at ../../gcc/gcc/tree-ssa-structalias.c:346
0x00f9570e in dump_constraint (file=0x27fd8e0, c=0x281fc38)
at ../../gcc/gcc/tree-ssa-structalias.c:678
678 fprintf (file, "%s", get_varinfo (c->lhs.var)->name);
Value returned is $27 = (variable_info *) 0x27cd7b0
(gdb) s
__GI__IO_fputs (str=0x7fffefba2050 '\245' , "\"",
fp=0x27fd8e0) at iofputs.c:32
32 {
(gdb) p $22
$28 = 0x7fffefba2050 '\245' , "\""
(gdb) bt
#0 __GI__IO_fputs (str=0x7fffefba2050 '\245' , "\"",
fp=0x27fd8e0) at iofputs.c:32
#1 0x00f95721 in dump_constraint (file=0x27fd8e0, c=0x281fc38)
at ../../gcc/gcc/tree-ssa-structalias.c:678
#2 0x00f958db in dump_constraints (file=0x27fd8e0, from=44)
at ../../gcc/gcc/tree-ssa-structalias.c:723
#3 0x00fa9d22 in ipa_pta_execute ()
at ../../gcc/gcc/tree-ssa-structalias.c:8193
#4
[Bug testsuite/91065] gcc.dg/plugin/start_unit_plugin.c uses ggc memory without registering a root_tab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91065 --- Comment #2 from Jorn Wolfgang Rennecke --- Author: amylaar Date: Wed Jul 3 00:22:53 2019 New Revision: 272954 URL: https://gcc.gnu.org/viewcvs?rev=272954&root=gcc&view=rev Log: PR testsuite/91065 * testsuite/gcc.dg/plugin/start_unit_plugin.c: Register a root tab to reference fake_var. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/start_unit_plugin.c
[Bug testsuite/91065] gcc.dg/plugin/start_unit_plugin.c uses ggc memory without registering a root_tab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91065 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jorn Wolfgang Rennecke --- Patch applied, not a regression, since the test was like this from the start.
[Bug libstdc++/91067] New: Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Bug ID: 91067 Summary: Clang compiler can't link executable if std::filesystem::directory_iterator is encountered Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: boris.staletic at gmail dot com Target Milestone: --- When compiling with clang, a code that contains an object of the type std::filesystem::directory_iterator produces the following linker error: /usr/sbin/ld: /tmp/bar-5627f7.o: in function `std::filesystem::__cxx11::directory_iterator::directory_iterator()': bar.cpp:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2Ev[_ZNSt10filesystem7__cxx1118directory_iteratorC2Ev]+0x1): undefined reference to `std::__shared_ptr::__shared_ptr()' clang-8: error: linker command failed with exit code 1 (use -v to see invocation) The minimal reproducer had to be preprocessed with clang to avoid errors like "/usr/include/c++/9.1.0/bits/stl_function.h:475:6: error: use of undeclared identifier '__builtin_is_constant_evaluated'" when compiling. For this reason I will attach a non-preprocessed file too. Clang version - 8.0.0 (tags/RELEASE_800/final) Clang command line - clang++ -std=c++17 bar.ii -O1 -lstdc++fs GCC version - 9.1.0 Target - x86_64-pc-linux-gnu GCC compile time configuration options: COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto Thread model: posix Additional note: Changing the optimization level can avoid the linker error.
[Bug libstdc++/91067] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #2 from Boris Staletic --- Created attachment 46549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46549&action=edit Non-preprocessed file
[Bug libstdc++/91067] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #1 from Boris Staletic --- Created attachment 46548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46548&action=edit Minimal reproducer - preprocessed with clang
[Bug rtl-optimization/90357] [9/10 regression][MIPS] New FAIL: gcc.c-torture/execute/20080502-1.c -O0 start with r269880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90357 Paul Hua changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Hua --- fixed on trunk and gcc-9-branch
[Bug libstdc++/91067] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-03 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.2 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- The symbol isn't exported from the shared lib.
[Bug rtl-optimization/91068] New: [10 regression][MIPS] New FAIL: madd-3.c and msub-5.c start with r272849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91068 Bug ID: 91068 Summary: [10 regression][MIPS] New FAIL: madd-3.c and msub-5.c start with r272849 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: paul.hua.gm at gmail dot com Target Milestone: --- The follow test fails between r272831 and r272852. FAIL: gcc.target/mips/madd-3.c -O1 scan-assembler-times \\tmadd\\t 3 FAIL: gcc.target/mips/madd-5.c -O1 scan-assembler-times \\tmadd\\t 4 FAIL: gcc.target/mips/madd-5.c -O1 scan-assembler-times \\tmflo\\t 3 FAIL: gcc.target/mips/madd-9.c -O1 scan-assembler \\tmadd\\t FAIL: gcc.target/mips/madd-9.c -O1 scan-assembler \\tmult\\t FAIL: gcc.target/mips/madd-9.c -O1 scan-assembler-not \\tmul\\t FAIL: gcc.target/mips/msub-5.c -O1 scan-assembler-times \\tmflo\\t 3 FAIL: gcc.target/mips/msub-5.c -O1 scan-assembler-times \\tmsub\\t 4 bisect show start with r272849.
