[Bug sanitizer/89298] New: Address-Sanitizer false positive for global-buffer-overflow?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89298
Bug ID: 89298
Summary: Address-Sanitizer false positive for
global-buffer-overflow?
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: lee_shao at 126 dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hi,
In my program, the ASAN report ERROR global-buffer-overflow on several global
variables.
However,I'm sure that I use the global variables in the right way, like this:
In AAA.c
//define a global var
int g_var_a;
g_var_a =1; //ASAN report global-buffer-overflow right here!
According to the formula, Shadow = (Mem >> 3) + 0x2000, the value of the
shadow memory of the global var **g_var_a** is F9 ( Global Redzone),witch
confuses me very much!
I use GCC8.1.0 to compile my project on SUSE Linux Enterprise Server 12.
The application is compiled like this:
1. A.c + B.c -> GCC8.1 ASan -> libproblem.so
2. C.c + libproblem.so --> GCC8.1 ASan --> App
3. In A.c :
... globals ...
unsigned int g_var =0;
... globals ...
In B.c :
extern unsigned int g_var =0;
..
void fun(){
.
g_var =0; //ASan report global-buffer-overflow right here!
.
}
I found that:
1. The global g_var is located 0 bytes to the right of another global
variable,that is , no redzone is inserted between them
2. Under normal circumstances， $ nm App > nm.log we can get the addresses of
globals g_var and __odr_asan.g_var ;
However, when it goes wrong, there is no symbol __odr_asan.g_var
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #23 from Martin Liška --- > > The purpose of the check is impose a limit on the size of the jumps that > occur within the location_t representation, so that if there's a big jump in > line numbers, we start a linemap, where big is "> 1000" within the > location_t value. The idea is to avoid wasting location_t values, without > creating too many linemap instances. Ah, I see, thanks for clarification!
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #24 from Martin Liška --- (In reply to David Malcolm from comment #22) > Should be fixed by r268789. Nice, thanks for test and cooperation.
[Bug sanitizer/89298] Address-Sanitizer false positive for global-buffer-overflow?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89298 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-12 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please provide a reproducer, as described here: https://www.gnu.org/software/gcc/bugs/minimize.html Thanks.
[Bug libbacktrace/81983] libbacktrace calls bsearch with NULL base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81983 Tom de Vries changed: What|Removed |Added Keywords||patch Status|WAITING |NEW --- Comment #6 from Tom de Vries --- https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00860.html
[Bug sanitizer/89298] Address-Sanitizer false positive for global-buffer-overflow?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89298 --- Comment #2 from Jakub Jelinek --- It is not clear how that can compile, because both unsigned int g_var =0; and extern unsigned int g_var =0; are g_var definitions, so if that is in multiple TUs, linker should fail to link that. In the other snippet you mention int g_var_a; which is something very different (unless -fno-common), that is a common var and ASAN doesn't instrument those.
[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 Thomas Koenig changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #13 from Thomas Koenig --- Thanks for the analysis (and the patch). Now for the interesting question, what to do with it... On the one hand, we must avoid at all costs is to break compatibility with pre-compiled libraries, at least while we do not change the ABI for another reason. On the other hand, this is quit a serious bug, which especially affects old Fortran codes. At least the problem is on the caller side, which means that we could fix the caller without affecting the callee. So, what are the options? After checking if the patch from comment #12 does the right thing (which I don't know), we could a) apply it globally, after checking that it does not break binary compatibility on all relevant platforms (quite risky for stage 4, I think) b) apply it #ifdefed for POWER I think both options would need an OK from a release manager due to us being in stage 4 (plus from a POWER maintainer for option b) Or we could defer this to gcc 10, but I would prefer for this bug to be fixed sooner rather than later.
[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 --- Comment #14 from rguenther at suse dot de --- On February 12, 2019 9:40:46 AM GMT+01:00, "tkoenig at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 > >Thomas Koenig changed: > > What|Removed |Added > > CC||rguenth at gcc dot gnu.org > >--- Comment #13 from Thomas Koenig --- >Thanks for the analysis (and the patch). Now for the >interesting question, what to do with it... > >On the one hand, we must avoid at all costs is to break >compatibility with pre-compiled libraries, at least while >we do not change the ABI for another reason. > >On the other hand, this is quit a serious bug, which especially >affects old Fortran codes. > >At least the problem is on the caller side, which means that >we could fix the caller without affecting the callee. > >So, what are the options? > >After checking if the patch from comment #12 does the right >thing (which I don't know), we could > >a) apply it globally, after checking that it does not break > binary compatibility on all relevant platforms (quite risky > for stage 4, I think) > >b) apply it #ifdefed for POWER > >I think both options would need an OK from a release manager due >to us being in stage 4 (plus from a POWER maintainer for option b) > >Or we could defer this to gcc 10, but I would prefer for this bug >to be fixed sooner rather than later. I haven't checked the details of the incorrectness of the function decl or its type. Given the error is on the caller side only the chances of breakage are low. Still I would suggest to fix on trunk only for now and skip the imminent 8.3 to allow for fallout to pop up. Richard.
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 MarkEggleston changed: What|Removed |Added Attachment #45657|0 |1 is obsolete|| --- Comment #6 from MarkEggleston --- Created attachment 45662 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45662&action=edit GNU extension to intrinsic SIGN Corrected patch.
[Bug c++/89299] New: __attribute__ cleanup does not accept template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89299
Bug ID: 89299
Summary: __attribute__ cleanup does not accept template
function
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: paradox_ptr at protonmail dot ch
Target Milestone: ---
#include
template
void cu( T** p ) {
if ( p && *p ) { free( *p ); }
}
void cu_char( char** s ) {
if ( s && *s ) { free ( *s ); }
}
int main() {
__attribute__((cleanup(cu))) char* s = nullptr;
return 0;
}
Using template function for cleanup yields error:
$ g++ main.cpp --std=c++14 -Wall -Wextra
main.cpp: In function ‘int main()’:
main.cpp:13:37: error: cleanup argument not a function
__attribute__((cleanup(cu))) char* s = nullptr;
^
main.cpp:13:37: warning: unused variable ‘s’ [-Wunused-variable]
Same for cleanup(cu). cleanup(cu_char) works, as expected.
Clearly, template function is still a function, especially when explicitly
instantiated.
GCC documentation for Common Variable Attributes does not state any limitations
for this function.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-8.2.0-r6/work/gcc-8.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 8.2.0-r6 p1.7' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--enable-vtable-verify --enable-libvtv --enable-lto --without-isl
--enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.2.0 (Gentoo 8.2.0-r6 p1.7)
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 MarkEggleston changed: What|Removed |Added Attachment #45659|0 |1 is obsolete|| --- Comment #7 from MarkEggleston --- Created attachment 45663 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45663&action=edit Change Log for gcc/testsuite for patch Corrected change log
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 --- Comment #8 from MarkEggleston --- (In reply to Dominique d'Humieres from comment #5) > Patch should go to the fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org > mailing lists for review. will do. > > From a quick look at the patch it does seem that the extension is rejected > when compiling with -std=f*. That is correct. The purpose is to bring the treatment of SIGN into line with that of DIM, MOD and MODULO which accept differing kinds in the their actual arguments when -std=gnu (i.e. the default). DIM, MOD and MODULO are also rejected when -std=f*. > > I don't see the need to add this extension (read: I am opposed to this > extension).
[Bug target/38959] Additional switches to disallow processor supplementary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38959
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #3 from Peter Cordes ---
We can maybe close this as fixed (if -march=i386 didn't exist/work at the time)
or invalid. Or maybe we want to add some CPU-level awareness to code-gen for
__builtin_ia32_rdtsc / rdpmc / rdtscp.
The cmov / fcomi / fcomi proposed switches are already supported as part of
-march=pentium -mtune=generic or lower, e.g. -march=i386. (The 32-bit default
is something like arch=i686 and tune=generic, with it being possible to
configure gcc so SSE2 is on by default in 32-bit code.)
Those are the important ones, because they're emitted automatically by the
compiler's back-end. The other options would just be trying to save you from
yourself, e.g. rejecting source that contains __rdtsc() /
__builtin_ia32_rdtsc()
I'm not sure what the situation is with long NOPs. GCC doesn't (normally?)
emit them, just using .p2align directives for the assembler. In 32-bit mode,
GAS appears to avoid long NOPs, using either 2-byte xchg ax,ax or pseudo-nops
like LEA esi,[esi+eiz*1+0x0] that add a cycle of latency to the dep chain
involving ESI.
Even with -march=haswell, gcc+gas fail to use more efficient long NOPs for
padding between functions.
---
I'm not sure if CPUID is ever emitted by gcc's back-end directly, only from
inline asm. i386/cpuid.h uses inline asm. But __get_cpuid_max() checks if
CPUID is even supported in a 386-compatible way, checking if a bit in EFLAGS is
sticky or not. If your source code is written safely, you won't have a problem
unless possibly __builtin_cpu_init runs CPUID without checking, in programs
that use __builtin_cpu_supports() or _is().
__builtin_ia32_rdpmc() and __rdtsc() do *not* check -march= before emitting
rdpmc and rdtsc. Neither does __rdtscp(), which is interesting because that
instruction is new enough that some still-relevant CPUs don't support it.
__rdpmc() isn't "volatile", though, so stop-start optimizes to 0. (I found
this bug looking for existing reports of that issue.)
Test cases: https://godbolt.org/z/hqPdza
FCMOV and CMOV are also handled correctly, but I didn't write functions for
them.
int fcomi(double x, double y) {
return x Proposed switches:
>
> --nocpuid This option causes the compiler to not generate cpuid opcodes
> --nocmov This option causes the compiler to not generate cmov opcodes
> --nofcmov This option causes the compiler to not generate fcmov opcodes
> --nofcomi This option causes the compiler to not generate fcomi opcodes
> --nonopl This option causes the compiler to not generate fcomi opcodes
> --nordpmc This option causes the compiler to not generate rdpmc opcodes
> --nordtsc This option causes the compiler to not generate rdtsc opcodes
>
> Possibly a general switch that is equivalent to all of the above
>
> --nosupplementaryinstructions
>
> Rationale
>
> It is possible that a developer still wants to compile for a particular
> architecture (for example the i486), but does not wish to generate code with
> supplementary instructions (such as cpuid), that may be present on that
> architecture.
[Bug target/38959] Additional switches to disallow processor supplementary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38959 --- Comment #4 from Peter Cordes --- The __builtin_ia32_rdpmc being a pure function bug I mentioned in my previous comment is already reported and fixed (in gcc9 only): bug 87550 It was present since at least gcc 5.0 https://software.intel.com/en-us/forums/software-tuning-performance-optimization-platform-monitoring/topic/595214
[Bug tree-optimization/89253] [8/9 Regression] ICE in split_loop, at tree-ssa-loop-split.c:566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89253 --- Comment #2 from Richard Biener --- Author: rguenth Date: Tue Feb 12 09:29:39 2019 New Revision: 268790 URL: https://gcc.gnu.org/viewcvs?rev=268790&root=gcc&view=rev Log: 2019-02-12 Richard Biener PR tree-optimization/89253 * tree-ssa-loop-split.c (tree_ssa_split_loops): Check we can duplicate the loop. * gfortran.dg/pr89253.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr89253.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-split.c
[Bug sanitizer/89298] Address-Sanitizer false positive for global-buffer-overflow?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89298 --- Comment #3 from Keerecles --- (In reply to Jakub Jelinek from comment #2) > It is not clear how that can compile, because both > unsigned int g_var =0; > and > extern unsigned int g_var =0; > are g_var definitions, so if that is in multiple TUs, linker should fail to > link that. No multiple definitions and the program is successfully compiled and linked. > In the other snippet you mention > int g_var_a; > which is something very different (unless -fno-common), that is a common var > and ASAN doesn't instrument those. Sorry, I made a mistake. In my application, ASAN reports global-buffer-overflow just on the global g_var. "int g_var_a;" should be "int g_var;" Here is the ASAN log : $ LD_PRELOAD=/usr/local/gcc-8.1/lib/libasan.so gdb ./App $ b ***/***/AAA.c:288 $ run $ Breakpoint 1 288 g_var=1; $ p &g_var $ $1 = (int) 0xe04e4620 $ n $ ==106196==ERROR: AddressSanitizer: global-buffer-overflow on address 0x08d09bc0 at pc 0xde57b983 bp 0xcfe8 sp 0xcfdc [Here the address (0x08d09bc0) is not 0xe04e4620 ] $ #0 0xde57b982 in ***/***/AAA.c:288 $ 0x08d09bc0 is located 0 bytes to the right of global variable 'g_var_others' defined in *** $ 0x08d09bc0 is located 0 bytes inside of global variable 'g_var' defined in ***
[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290
--- Comment #2 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> then the ix86_rewrite_tls_address splitter rewrites this into:
> (insn 12 6 10 2 (set (mem/c:TI (const:DI (unspec:DI [
> (symbol_ref:DI ("s") [flags 0x2a] 0x7ff97a130b40 s>)
> ] UNSPEC_NTPOFF)) [1 s+0 S16 A64 AS1])
> (reg:TI 83)) "pr89290.c":7:5 -1
> (nil))
> and finally we ICE in the split_double_move splitter.
The address is constant and offsettable_address_addr_space_p claims that the
address
(const:DI (unspec:DI [
(symbol_ref:DI ("s") [flags 0x2a] )
] UNSPEC_NTPOFF))
is offsettable due to:
if (CONSTANT_ADDRESS_P (y))
return 1;
So, we should probably allow addresses in the form of:
movq%rax, %fs:s+8@tpoff
[Bug bootstrap/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 --- Comment #4 from Дилян Палаузов --- If an impossible combination is requested, then ./configure shall fail
[Bug c++/89300] New: C++ requires statement does not fail silently for const void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89300
Bug ID: 89300
Summary: C++ requires statement does not fail silently for
const void *
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: svenja.mehringer at gmail dot com
Target Milestone: ---
The following code snippet fails to compile with GCC 8.1/8.2/latest trunk on
Godbolt because of the requires clause. From my understanding, the requires
should just evaluate to false and remove the second foo overload from the list
of possible candidates.
```cpp
#include
template
void foo()
{}
template
requires requires { std::is_integral_v() -
std::declval())>; }
void foo()
{}
int main()
{
foo();
}
```
see https://godbolt.org/z/iFW2MO
The same code compiles fine with the clang experimental concept branch.
The error message:
```
: In function 'int main()':
:8:71: error: invalid use of 'const void'
requires requires { std::is_integral_v() -
std::declval())>; }
~~^~~
Compiler returned: 1
```
Locally reproduced on :
Using built-in specs.
COLLECT_GCC=/import/GCC//8.2.0/bin/g++
COLLECT_LTO_WRAPPER=/import/GCC/8.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/data/scratch/skillen1105/gcc8.2/dest
Thread model: posix
gcc version 8.2.0 (GCC)
[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290
--- Comment #3 from Uroš Bizjak ---
This address should be valid:
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("s") [flags 0x2a] )
] UNSPEC_NTPOFF)
(const_int 8 [0x8])))
and there is code that allows this form in ix86_legitimate_address_p:
/* foo@dtpoff(%rX) is ok. */
if (GET_CODE (disp) != CONST
|| GET_CODE (XEXP (disp, 0)) != PLUS
|| GET_CODE (XEXP (XEXP (disp, 0), 0)) != UNSPEC
|| !CONST_INT_P (XEXP (XEXP (disp, 0), 1))
|| (XINT (XEXP (XEXP (disp, 0), 0), 1) != UNSPEC_DTPOFF
&& XINT (XEXP (XEXP (disp, 0), 0), 1) != UNSPEC_NTPOFF))
/* Non-constant pic memory reference. */
return false;
Jakub, can you maybe look into this issue?
[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290
--- Comment #4 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #3)
> This address should be valid:
>
> (const:DI (plus:DI (unspec:DI [
> (symbol_ref:DI ("s") [flags 0x2a] s>)
> ] UNSPEC_NTPOFF)
> (const_int 8 [0x8])))
>
> and there is code that allows this form in ix86_legitimate_address_p:
>
> /* foo@dtpoff(%rX) is ok. */
> if (GET_CODE (disp) != CONST
> || GET_CODE (XEXP (disp, 0)) != PLUS
> || GET_CODE (XEXP (XEXP (disp, 0), 0)) != UNSPEC
> || !CONST_INT_P (XEXP (XEXP (disp, 0), 1))
> || (XINT (XEXP (XEXP (disp, 0), 0), 1) != UNSPEC_DTPOFF
> && XINT (XEXP (XEXP (disp, 0), 0), 1) != UNSPEC_NTPOFF))
> /* Non-constant pic memory reference. */
> return false;
>
> Jakub, can you maybe look into this issue?
I will, probably by looking at why it works fine without -mcmodel=large,
because in that case it generates those CONSTs with PLUS, UNSPEC_NTPOFF and
CONST_INT offset.
[Bug c++/89301] New: [concepts] requires clause on a template alias is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89301
Bug ID: 89301
Summary: [concepts] requires clause on a template alias is
ignored
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
The following code compiles however it should not:
template
requires(condition)
using enable_if_t = T;
template>
void foo();
void test() {
foo();
}
Slightly changed example also compiles on GCC (but fails to compile on Clang):
template
requires(condition)
using enable_if_t = T;
template
enable_if_t foo();
void test() {
foo();
}
[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290 --- Comment #5 from Uroš Bizjak --- Created attachment 45664 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45664&action=edit Untested patch Kind of a proposed patch that fixes the testcase. More or less shot in the dark, as this is not really my area of experience.
[Bug c++/89300] C++ requires statement does not fail silently for const void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89300 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-12 Ever confirmed|0 |1
[Bug c++/89299] __attribute__ cleanup does not accept template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89299 --- Comment #1 from Jonathan Wakely --- That attribute doesn't really make sense in C++, because you have destructors anyway, so I would think that making it work with C++ templates is very low priority.
[Bug hsa/89302] New: libgomp.c-c++-common/for-11.c fails when offloaded to HSA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89302 Bug ID: 89302 Summary: libgomp.c-c++-common/for-11.c fails when offloaded to HSA Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: hsa Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I can see the following two libgomp failures when the testsuite is run on an HSA-capable machine and HSA offloading is enabled. libgomp.c/../libgomp.c-c++-common/for-11.c execution test libgomp.c++/../libgomp.c-c++-common/for-11.c execution test The reason is that gridification cannot cope with != operator in OpenMP loops. A fix has been proposed on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00105.html
[Bug c++/89299] __attribute__ cleanup does not accept template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89299 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-12 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to paradox_ptr from comment #0) > Clearly, template function is still a function, No it isn't, it's a template. > especially when explicitly > instantiated. Well you didn't instantiate it. 'cu' is not a function, it's a template. But it still doesn't compile if you use __attribute__((cleanup(cu))). In theory the compiler could deduce the template arguments from the type of the variable, but IMHO it's completely unnecessary to use this extension in C++ anyway, so adding complexity to it is a waste of resources.
[Bug c++/89299] __attribute__ cleanup does not accept template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89299 --- Comment #3 from paradox_ptr at protonmail dot ch --- > Well you didn't instantiate it. 'cu' is not a function, it's a template. Sure. There is not enough information for the compiler to deduce the type without <>. > IMHO it's completely unnecessary to use this extension in C++ anyway Fair enough. However I feel like error message is plain incorrect for cleanup(cu).
[Bug c++/89301] [concepts] requires clause on a template alias is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89301 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-12 Ever confirmed|0 |1
[Bug c++/89303] New: memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303
Bug ID: 89303
Summary: memory leak with shared_ptr and
enable_shared_from_this
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adl at gnu dot org
Target Milestone: ---
I'm not sure if this issue is compiler or library related, but since changing
-O into -O0 or -O2 hides the issue, I'm assuming its the compiler.
This is g++ 8.2.0-20 from Debian unstable (SVN 20190209 (r268721) from the
gcc-8-branch) running on amd64.
% cat issue.c
#include
class blob final: public std::enable_shared_from_this
{
int* data;
public:
blob() { data = new int; }
~blob() { delete data; }
};
static int
bar(std::shared_ptr)
{
return 0;
}
int main()
{
std::shared_ptr tg = std::make_shared();
return bar(tg);
}
% g++ -Wall -g -O issue.cc
% valgrind -q --leak-check=full ./a.out
==13174== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==13174==at 0x4835DEF: operator new(unsigned long)
(vg_replace_malloc.c:334)
==13174==by 0x1092F5: allocate (new_allocator.h:111)
==13174==by 0x1092F5: allocate (alloc_traits.h:436)
==13174==by 0x1092F5:
__allocate_guarded, (__gnu_cxx::_Lock_policy)2> > > (allocated_ptr.h:97)
==13174==by 0x1092F5: __shared_count >
(shared_ptr_base.h:675)
==13174==by 0x1092F5: std::__shared_ptr::__shared_ptr>(std::_Sp_alloc_shared_tag
>) (shared_ptr_base.h:1342)
==13174==by 0x109185: shared_ptr > (shared_ptr.h:359)
==13174==by 0x109185: allocate_shared >
(shared_ptr.h:706)
==13174==by 0x109185: make_shared (shared_ptr.h:722)
==13174==by 0x109185: main (issue.cc:20)
==13174==
I've confirmed that this leak exist using GNU libc's mtrace(), i.e., this is
not a valgrind bug.
Note that changing -O into -O0 or -O2 removes the leak.
This is a reduced test case from a larger project that started leaking memory
after I upgraded Debian unstable's g++-8 package from version 8.2.0-13 to
version 8.2.0-16. I also have some tests that started raising bad_weak_ptr
exceptions, but so far I haven't reduced those.
Note that 8.2.0-16 includes the patch for libstdc++/88782 ; could this be
related?
[Bug c++/89303] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-12 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I can't reproduce this with GCC 8.2.1 or 9.0.1, so it might be a problem with the Debian package. Please provide preprocessed source.
[Bug c++/89303] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Jonathan Wakely --- Oh I take it back, I do see it on gcc-8-branch (but not trunk).
[Bug libstdc++/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Component|c++ |libstdc++ Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Summary|memory leak with shared_ptr |[8 Regression] memory leak |and enable_shared_from_this |with shared_ptr and ||enable_shared_from_this
[Bug libstdc++/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 --- Comment #3 from Alexandre Duret-Lutz --- Created attachment 45665 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45665&action=edit preprocessed source Here is the preprocessed source.
[Bug c++/89304] New: Compiler runs indefinitely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89304
Bug ID: 89304
Summary: Compiler runs indefinitely
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code leads to g++ (and also clang++) running indefinitely. It
needs to be compiled with -std=c++17.
#include
template
void p(T const & v)
{
}
template
void f(T &&... args);
template
void f(std::tuple const & args);
template
void f(T &&... args)
{
auto t = std::make_tuple(args...);
f(t);
}
template
void f(std::tuple const & args)
{
std::apply([](auto const &... v) { (..., p(v)); }, args);
}
int main()
{
f(1., 2, 4);
return 0;
}
[Bug target/88777] [9 Regression] Out-of-range offsets building glibc test-tgmath2.c for hppa-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777 --- Comment #7 from Jan Hubicka --- Author: hubicka Date: Tue Feb 12 11:25:11 2019 New Revision: 268791 URL: https://gcc.gnu.org/viewcvs?rev=268791&root=gcc&view=rev Log: PR lto/88777 * cgraphunit.c (analyze_functions): Clear READONLY flag for external types that needs constructiong. * tree.h (may_be_aliased): Do not check TYPE_NEEDS_CONSTRUCTING. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/tree.h
[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 --- Comment #15 from Alan Modra --- I've regression tested the patch on powerpc64le-linux, and of course verified that it fixes the testcase. I'm also fairly certain the patch intent is correct in the narrow sense of it correcting gfc_get_function_type behaviour. My comment about not being let loose near the gcc fortran support is because I have no idea whether the patch is the best patch possible. Also, as with any patch, reviewers should check the actual patch matches the intent. ;-) gfc_get_function_type currently calls build_varargs_function_type_vec for "normal" functions without arg info, which seems a perfectly reasonable way to say the function isn't prototyped. So the patch isn't introducing new behaviour.. By "normal" I mean functions that don't have hidden args for return values or multiple entry points. Just because you have arg info for the return type shouldn't make the function prototyped.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285
--- Comment #10 from Jakub Jelinek ---
Created attachment 45666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45666&action=edit
gcc9-pr89285-wip.patch
Non-working WIP.
I've tried this, thinking that we don't really need to duplicate decls etc. in
the function and could just copy the statements. Unfortunately, there are
issues with that:
1) the genericization modifies in place the PARM_DECLs and RESULT_DECL, so
mixing the pre-cp_fold_function/cp_genericize* statements (body) with the post
cp_genericize* is not going to work flawlessly
2) apparently cxx_eval_constant_expression assumes post genericization IL:
if (STATEMENT_CODE_P (TREE_CODE (t)))
{
/* This function doesn't know how to deal with pre-genericize
statements; this can only happen with statement-expressions,
so for now just fail. */
if (!ctx->quiet)
error_at (EXPR_LOCATION (t),
"statement is not a constant expression");
}
so it is upset e.g. about WHILE_STMT and others.
>From the language conformance POV though, I think it is highly desirable to
evaluate constexpr functions on the original, pre-folding/genericization,
trees, because the middle-end (e.g. match.pd, fold-const.c) is not willing to
guarantee not to fold away stuff that should be diagnosed as constexpr
violations.
So, for 1), I'd think we could just use copy_fn and remember not just the body,
but also parms and result in constexpr_fundef
For 2), I guess that would mean teaching constexpr.c about the
pre-genericization *_STMT constructs.
[Bug c++/89304] Compiler runs indefinitely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89304
Jonathan Wakely changed:
What|Removed |Added
Keywords||compile-time-hog
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
I think f(t) recurses forever, it can be reduced to:
#include
template
void f(T &&... args)
{
auto t = std::make_tuple(args...);
f(t);
}
int main()
{
f(1., 2, 4);
}
Which can be reduced to:
template struct tuple { };
template
tuple
make_tuple(T...)
{
return tuple{};
}
template
void f(tuple const& args) { }
template
void f(T&&... args)
{
auto t = make_tuple(args...);
f(t);
}
int main()
{
f(1., 2, 4);
}
This fails much faster:
89304.cc: In instantiation of 'void f(T&& ...) [with T =
{tuple > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >&}]':
89304.cc:20:4: recursively required from 'void f(T&& ...) [with T =
{tuple&}]'
89304.cc:20:4: required from 'void f(T&& ...) [with T = {double, int, long
int}]'
89304.cc:25:13: required from here
89304.cc:19:22: fatal error: template instantiation depth exceeds maximum of
900 (use -ftemplate-depth= to increase the maximum)
19 | auto t = make_tuple(args...);
|~~^
compilation terminated.
The problem is that calling f(tuple const&) requires a qualification
conversion, but (recursively) calling f(T&&...) requires no conversion
sequence, so is a better match.
[Bug c++/89304] Compiler runs indefinitely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89304 --- Comment #2 from Jonathan Wakely --- This will work, because there's no conversion needed from tuple to tuple const, so the expected overload is more speclialized: const auto t = std::make_tuple(args...); f(t);
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #11 from Jakub Jelinek --- Created attachment 45667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45667&action=edit gcc9-pr89285-wip.patch Updated patch to address 1). For 2), I guess we need to handle e.g. CLEANUP_STMT, IF_STMT, FOR_STMT, WHILE_STMT, DO_STMT, SWITCH_STMT, CONTINUE_STMT, BREAK_STMT in cxx_eval_constant_expression.
[Bug c++/89304] Compiler runs indefinitely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89304 --- Comment #3 from Jonathan Wakely --- With -ftemplate-depth=50 it fails in about 5 seconds. -ftemplate-depth=100 takes 18s -ftemplate-depth=200 takes 1m27s So there's something quadratic in the nested tuple instantiations which means that reaching the default template depth of 900 takes a silly length of time.
[Bug ipa/88818] Segfault with vtable-verify LTO optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88818 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- Created attachment 45668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45668&action=edit C++ source code
[Bug ipa/88818] Segfault with vtable-verify LTO optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88818 --- Comment #5 from David Binderman --- The attached code does something similar: $ ~/gcc/results/bin/gcc -c -O2 -flto -fvtable-verify=std -std=gnu++11 bug504.cc during GIMPLE pass: ealias bug504.cc: In function ‘_GLOBAL__sub_I.00099__ZSt27__replacement_assert___file’: bug504.cc:5632:56: internal compiler error: in operator[], at vec.h:845 5632 | };
[Bug c++/89305] New: CWG DR 253 is not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89305
Bug ID: 89305
Summary: CWG DR 253 is not implemented
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raphael.kubo.da.costa at intel dot com
Target Milestone: ---
I can see a few bugs marked as SUSPENDED related to DR 253 and how there hadn't
been an official resolution at the time.
According to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0490r0.html and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#253 it's part of
C++17 (even though MSVC and clang implement it for older versions as well).
IOW, I believe G++ should accept the following code:
struct S {
};
struct T {
T() {}
const S s_;
};
rather than failing with
const.cc: In constructor ‘T::T()’:
const.cc:5:3: error: uninitialized const member in ‘const struct S’
[-fpermissive]
T() {}
^
const.cc:6:11: note: ‘const S T::s_’ should be initialized
const S s_;
^~
[Bug fortran/88076] Shared Memory implementation for Coarrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076 --- Comment #9 from Nicolas Koenig --- Sorry for the late reply, there was a sad incidence with my laptop and ice cream :D (In reply to Damian Rouson from comment #8) > (In reply to Nicolas Koenig from comment #7) > > > I actually opted to use multiprocessing with shared memory (shm_open() & co) > > instead of multithreading, since it will be much easier and faster with > > static variables, of which gfortran makes extensive use. Also, it greatly > > simplifies interoperability with OpenMP. > > This sounds like a great choice. I have no prior familiarity with > shm_open(), > but I very much like the idea of simplifying interoperability with OpenMP. > > > The only real downsides I can think of are slower spinup times... > > It will be interesting to compare the performance with MPI. I also wonder if > this would also someday provide for a hybrid implementation wherein > shm_open() > is used within a node and MPI is used across nodes, e.g., maybe images within > a TEAM could use shm_open() to communicate, while any communication between > TEAMs could use MPI. > I think that would be ideal. The only problem with this would be that we would have to maintain 3 implementations, which would be quite work intensive. > > > > > I actually think it would be best not to turn it into a separate library but > > instead integrate it into libgfortran. > > I agree. > > > This way, it will not be necessary to > > install a seperate library and thereby make it easier for people to start > > using coarrays. Therefore, it would make sense to use the libgfortran > > descriptors. > > > > > At the moment, sync_all() is called after image creation. > > I think that will suffice.
[Bug fortran/88076] Shared Memory implementation for Coarrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076 Nicolas Koenig changed: What|Removed |Added Attachment #45535|0 |1 is obsolete|| --- Comment #10 from Nicolas Koenig --- Created attachment 45669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45669&action=edit Proof-of-concept v2 Also, here is an updated version that adds (preliminary) support for implicit coarray accesses and coarrays in modules as well as fixing some bugs in the old one. It is now capable of compiling and running the following simple test: module co integer:: a[*] end module program main use co, only: a implicit none a[next_image()] = this_image() sync all print *, 'Hi from', a, 'to', this_image() contains function next_image() integer:: next_image next_image = mod(this_image(), num_images()) + 1 end function end program
[Bug target/38959] Additional switches to disallow processor supplementary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38959 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from Alexander Monakov --- As far as I can tell this report was not correctly triaged 10 years ago, as that's exactly what -mtune= is for: optimize for a given CPU without assuming availability of its ISA extensions. So from compiler perspective something like -march=i386 -mtune=i486 gives the requested behavior, and any strict enforcement is a job for the assembler, not the compiler. So let's close as invalid.
[Bug fortran/88076] Shared Memory implementation for Coarrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076 Nicolas Koenig changed: What|Removed |Added Attachment #45536|0 |1 is obsolete|| --- Comment #11 from Nicolas Koenig --- Created attachment 45670 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45670&action=edit library v2 Here is the new version of the library. They should really add the ability to attach more than one file. I will ask the mailing list about integration with libgfortran.
[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 #3 from Martin Liška --- Author: marxin Date: Tue Feb 12 13:46:41 2019 New Revision: 268795 URL: https://gcc.gnu.org/viewcvs?rev=268795&root=gcc&view=rev Log: Revert a hunk from r261322 (PR lto/88876). 2019-02-12 Martin Liska PR lto/88876 * ipa-pure-const.c (propagate_pure_const): Revert hunk as we need default values of funct_state for a function that is not optimized. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c
[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug c++/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug c++/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Component|libstdc++ |c++ --- Comment #4 from Jonathan Wakely --- The test behaves correctly if -O1 is combined with any (one or more) of: -fno-guess-branch-probability -fno-inline-functions-called-once -fno-tree-forwprop -fno-tree-fre -fno-tree-pta The bug did appear with the r268114 change to shared_ptr but that seems to have just exposed a latent compiler bug. It appears that the enable_shared_from_this destructor doesn't run after ~blob() runs, and so the _M_weak_count member is not decremented by that destructor. As a result, once the last shared_ptr drops its reference the weak count remains above zero and so the control block is never destroyed.
[Bug libbacktrace/81983] libbacktrace calls bsearch with NULL base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81983 --- Comment #7 from Tom de Vries --- Author: vries Date: Tue Feb 12 14:00:59 2019 New Revision: 268796 URL: https://gcc.gnu.org/viewcvs?rev=268796&root=gcc&view=rev Log: [libbacktrace] Handle bsearch with NULL base in dwarf_lookup_pc The call to bsearch in dwarf_lookup_pc can have NULL as base argument when the nmemb argument is 0. The base argument is required to be pointing to the initial member of an array of nmemb objects. It is not specified what constitutes a valid pointer to an array of 0 objects, but glibc declares base with attribute non-null, so the NULL will trigger a sanitizer runtime error. Fix this by only calling bsearch if nmemb != 0. 2019-02-12 Tom de Vries PR libbacktrace/81983 * dwarf.c (dwarf_lookup_pc): Don't call bsearch if nmemb == 0. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/dwarf.c
[Bug libbacktrace/81983] libbacktrace calls bsearch with NULL base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81983 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #8 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #12 from Jakub Jelinek --- Created attachment 45671 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45671&action=edit gcc9-pr89285-wip.patch Updated version that handles the above mentioned C++ stmt trees. That said, there are still various regressions: /usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:636:48: in 'constexpr' expansion of 'std::vector >::_S_use_relocate()' /usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:636:8: error: modification of '#'result_decl' not supported by dump_expr#' is not a constant expression etc.
[Bug rtl-optimization/89242] [7/8/9 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89242 --- Comment #2 from Martin Liška --- I've got a patch candidate for it, testing now..
[Bug ipa/89306] New: [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89306
Bug ID: 89306
Summary: [8/9 regression] Hash based IPA summaries are too slow
and consume up to 80% of IPA optimization time.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
IPA summaries was switches to new nice C++ API but while doing so the original
array based scheme was replaced by hash tables. This is too slow for those
summaries which are dense (i.e. defined for almost all functions or variables
with a definition) and intensively used. These are:
ipa-inline-analysis.c:call_summary
*edge_growth_cache = NULL;
ipa-fnsummary.c:call_summary *ipa_call_summaries;
ipa-fnsummary.c:function_summary *ipa_fn_summaries;
ipa-pure-const.c:class funct_state_summary_t: public function_summary
ipa-pure-const.c:function_summary (symtab) {}
ipa-reference.c:function_summary (symtab) {}
This one may not get too dense in all cases and at ltrans it is populated for
non-definitions, but needs to be fast for alias oracle walks:
ipa-reference.c:function_summary
(symtab) {}
[Bug rtl-optimization/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303
Richard Biener changed:
What|Removed |Added
Component|c++ |rtl-optimization
Version|unknown |8.2.1
--- Comment #5 from Richard Biener ---
GIMPLE at -O1 looks OK-ish - release on all paths:
main ()
{
struct allocator D.41475;
struct _Sp_make_shared_tag D.41474;
struct shared_ptr tg;
struct _Sp_counted_base * _5;
struct _Sp_counted_base * _16;
_Atomic_word * _17;
int _18;
int _19;
[local count: 1073741825]:
std::__shared_ptr::__shared_ptr > (&tg.D.36194,
D.41474, &D.41475);
D.41475 ={v} {CLOBBER};
_16 = MEM[(const struct __shared_count &)&tg + 8]._M_pi;
if (_16 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619277]:
if (__gthrw___pthread_key_create != 0B)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 401890827]:
_17 = &_16->_M_use_count;
__atomic_fetch_add_4 (_17, 1, 4);
goto ; [100.00%]
[local count: 349728449]:
_18 = MEM[(_Atomic_word *)_16 + 8B];
_19 = _18 + 1;
MEM[(_Atomic_word *)_16 + 8B] = _19;
goto ; [100.00%]
[local count: 1073741824]:
_5 = MEM[(struct __shared_count *)&tg + 8B]._M_pi;
if (_5 != 0B)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 574129753]:
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (_5);
[local count: 1073741824]:
tg ={v} {CLOBBER};
return 0;
[local count: 574129754]:
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (_16);
goto ; [100.00%]
[Bug ipa/89306] [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89306 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine then.
[Bug c++/89297] ICE: unexpected expression 'id' of kind overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89297 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-12 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r268321.
[Bug target/89233] [9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89233
--- Comment #3 from iii at gcc dot gnu.org ---
Author: iii
Date: Tue Feb 12 14:51:39 2019
New Revision: 268798
URL: https://gcc.gnu.org/viewcvs?rev=268798&root=gcc&view=rev
Log:
S/390: Reject invalid Q/R/S/T addresses after LRA
The following insn:
(insn (set (reg:DI %r2)
(sign_extend:DI (mem:SI
(const:DI (plus:DI (symbol_ref:DI ("*.LC0"))
(const_int 16)))
is correctly recognized by LRA as RIL alternative of extendsidi2
define_insn. However, when recognition runs after LRA, it returns RXY
alternative, which is incorrect, since the offset 16 points past the
end of of *.LC0 literal pool entry. Such addresses are normally
rejected by s390_decompose_address ().
This inconsistency confuses annotate_constant_pool_refs: the selected
alternative makes it proceed with annotation, only to find that the
annotated address is invalid, causing ICE.
This patch fixes the root cause, namely, that s390_check_qrst_address ()
behaves differently during and after LRA.
gcc/ChangeLog:
2019-02-12 Ilya Leoshkevich
PR target/89233
* config/s390/s390.c (s390_decompose_address): Update comment.
(s390_check_qrst_address): Reject invalid address forms after
LRA.
gcc/testsuite/ChangeLog:
2019-02-12 Ilya Leoshkevich
PR target/89233
* gcc.target/s390/pr89233.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/s390/pr89233.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303
--- Comment #6 from Alexandre Duret-Lutz ---
I mentioned in my first comment that I had also cases that threw bad_weak_ptr.
I've been able to reproduce those as follows:
% cat badwptr.cc
#include
class blob final: public std::enable_shared_from_this
{
};
int main()
{
std::shared_ptr tg = std::make_shared();
return tg->shared_from_this().use_count();
}
% g++ -g -O badwptr.cc
% ./a.out
terminate called after throwing an instance of 'std::bad_weak_ptr'
what(): bad_weak_ptr
When compiled with -O2 or -O0, the program exits with $?=2 as expected.
[Bug rtl-optimization/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 --- Comment #7 from Jonathan Wakely --- Created attachment 45672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45672&action=edit Reduced testcase This (partially) reduced version fails with 8.2.1 or trunk when -O1 is used.
[Bug go/89277] [9 Regression] libgo memory hogs in libgo testsuite (at least on s390x-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89277 rdapp at linux dot ibm.com changed: What|Removed |Added CC||rdapp at linux dot ibm.com --- Comment #1 from rdapp at linux dot ibm.com --- Guessing this is the same problem as in PR89123 (triggering a panic in a panic, never stopping to allocate memory). I already proposed a patch that might also help here.
[Bug rtl-optimization/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 --- Comment #8 from Jonathan Wakely --- (In reply to Richard Biener from comment #5) > GIMPLE at -O1 looks OK-ish - release on all paths: But release decrements the weak_count, and only calls _M_destroy() if the count reaches zero. The attachment in comment 7 removes all the atomics and still shows the same problem.
[Bug rtl-optimization/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > (In reply to Richard Biener from comment #5) > > GIMPLE at -O1 looks OK-ish - release on all paths: > > But release decrements the weak_count, and only calls _M_destroy() if the > count reaches zero. And the problem is that a call to weak_release() from the enable_shared_from_this dtor is missing, so the count never reaches zero.
[Bug rtl-optimization/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Richard Biener from comment #5)
> > GIMPLE at -O1 looks OK-ish - release on all paths:
>
> But release decrements the weak_count, and only calls _M_destroy() if the
> count reaches zero.
>
> The attachment in comment 7 removes all the atomics and still shows the same
> problem.
Compiling it with -DFIXME adds:
else __builtin_puts("null");
in _M_weak_release(), and that fixes it despite that else branch never actually
being taken. Just the presence of I/O appears to prevent that function being
misoptimized.
[Bug c++/89305] CWG DR 253 is not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89305 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-12 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The resolution to the DR goes a bit further than the rule GCC has been using: A class type T is const-default-constructible if default-initialization of T would invoke a user-provided constructor of T (not inherited from a base class) or if - each direct non-variant non-static data member M of T has a default member initializer or, if M is of class type X (or array thereof), X is const-default-constructible, - if T is a union with at least one non-static data member, exactly one variant member has a default member initializer, - if T is a not a union, for each anonymous union member with at least one non-static data member (if any), exactly one non-static data member has a default member initializer, and - each potentially constructed base class of T is const-default-constructible.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 Jakub Jelinek changed: What|Removed |Added Attachment #45666|0 |1 is obsolete|| Attachment #45667|0 |1 is obsolete|| Attachment #45671|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek --- Created attachment 45673 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45673&action=edit gcc9-pr89285-wip.patch Updated WIP patch. There are still various regressions, but it is getting better. Before I continue further on this, I'd like to know if I'm not going completely in a wrong direction.
[Bug gcov-profile/89307] New: -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307 Bug ID: 89307 Summary: -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- I fill in to track the problem of cacheline conflicts which is also dicussed in LLVM variant in http://lists.llvm.org/pipermail/llvm-dev/2014-April/072172.html
[Bug c/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 --- Comment #11 from Martin Sebor --- There is no reliable way. The limit may not be fixed, or can be different for different directives or format strings. A test case like the one in the Red Hat bug #441945 linked at comment #2 might tell you there is a limit but not necessarily what it is. A case that interposes a custom malloc/free that fails at different points/different sizes might expose other limits (or bugs) altogether. If that doesn't cause any trouble it's pretty safe to assume that there is no limit. I tried both approaches with a few systems in the compile farm (I think AIX, FreeBSD, NetBSD, Glibc, and Solaris) and only got Glibc to fail (as in either return an error or crash).
[Bug sanitizer/89308] New: The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 Bug ID: 89308 Summary: The sanitizers do no longer work on GCC 8 with newer kernels Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- For GCC 9 we have fixes, but those are pretty big to backport. What shall we do?
[Bug sanitizer/89308] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 Segher Boessenkool changed: What|Removed |Added Target||powerpc*-*-* Priority|P3 |P1 CC||seurer at gcc dot gnu.org
[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I think the right fix is: --- gcc/config/i386/predicates.md.jj2019-01-01 12:37:32.267727037 +0100 +++ gcc/config/i386/predicates.md 2019-02-12 17:07:15.937097266 +0100 @@ -182,7 +182,7 @@ rtx op1 = XEXP (XEXP (op, 0), 0); rtx op2 = XEXP (XEXP (op, 0), 1); - if (ix86_cmodel == CM_LARGE) + if (ix86_cmodel == CM_LARGE && GET_CODE (op1) != UNSPEC) return false; if (!CONST_INT_P (op2)) return false; Even with -mcmodel=large, it is ok to offset the TLS LE by signed 32-bit constants, we don't really support > 2GB thread local segments, we don't have relocations for that etc. and nobody with sane mind should expect that to work.
[Bug c++/89299] __attribute__ cleanup does not accept template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89299 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- I agree that making attribute cleanup work with templates is low priority in C++ but I'm curious about the use case: can you describe what you are using the attribute for in C++? FWIW, I'm interested in this because the copy attribute and __builtin_has_attribute() function newly added in GCC 9 will ultimately need to handle templates so when the handling is implemented there we may be able to reuse it for this attribute as well.
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-12 Known to work||9.0 Target Milestone|--- |8.4 Summary|The sanitizers do no longer |[8 only] The sanitizers do |work on GCC 8 with newer|no longer work on GCC 8 |kernels |with newer kernels Ever confirmed|0 |1
[Bug c++/89309] New: bogus -Wattributes ‘copy’ attribute ignored on a declaration of a different kind than referenced symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89309
Bug ID: 89309
Summary: bogus -Wattributes ‘copy’ attribute ignored on a
declaration of a different kind than referenced symbol
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: ---
The copy attribute newly introduced in GCC 9 (see pr81824) doesn't handle C++
templates entirely correctly. The test case below shows that it successfully
copies the noreturn attribute from f to g but in the process it also
issues a spurious warning.
$ cat z.C && gcc -S -Wall z.C
template __attribute__ ((noreturn)) T f ();
template
__attribute__ ((copy (f))) T g () // bogus -Wattributes
{
f();
} // no -Wreturn-type (good)
template int g();
z.C: In substitution of ‘template T g() [with T = int]’:
z.C:9:21: required from here
z.C:4:33: warning: ‘copy’ attribute ignored on a declaration of a different
kind than referenced symbol [-Wattributes]
4 | __attribute__ ((copy (f))) T g () // bogus -Wattributes
| ^
[Bug c++/89309] bogus -Wattributes ‘copy’ attribute ignored on a declaration of a different kind than referenced symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89309 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-12 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Unless this is viewed as a regression I will handle it for GCC 10.
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 --- Comment #1 from Jakub Jelinek --- So, which exact changes (e.g. upstream svn revisions) we are talking about here?
[Bug tree-optimization/89296] [7/8/9 Regression] tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.6.3 Keywords||diagnostic Last reconfirmed||2019-02-12 CC||msebor at gcc dot gnu.org Blocks||24639 Ever confirmed|0 |1 Summary|tree copy-header masking|[7/8/9 Regression] tree |uninitialized warning |copy-header masking ||uninitialized warning Known to fail||4.7.4, 4.8.4, 4.9.4, 5.5.0, ||6.4.0, 7.2.0, 8.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed as a 4.7 regression. The most likely change of those my bisection points to is r177667. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug c/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 Franz Sirl changed: What|Removed |Added CC||sirl at gcc dot gnu.org --- Comment #12 from Franz Sirl --- What about moving this part of -Wformat-overflow=2 under -Woverlength-strings? Or let it trigger only when -Wformat-overflow=2 and -Woverlength-strings are in effect?
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
--- Comment #5 from lavr at ncbi dot nlm.nih.gov ---
Thank you Martin, for giving me the idea of where the problem might be stemming
from! It does look like *printf() is not recognized by GCC as not modifying
the local memory. But in your example GCC _might_ think that "p" and "q" can
be aliased (being the result of the same function).
Below is a mockup of the code that I was dealing with, clearly showing that "s"
and "h" cannot be aliased! "s" is being on the local frame all alone. I get
the same "uninitialized" warning if BUG is defined:
$ cat bogus2.c
#include
#include
#include
struct S {
int a;
int b;
};
struct H {
int c;
int d;
};
void getblk(void* blk)
{
struct S* s = (struct S*) blk;
memset(blk, 0, 512);
s->a = rand() & 1;
}
struct H* gethdr(void* blk)
{
memset(blk, 0, 512);
return rand() & 1 ? (struct H*) blk : 0;
}
int main(void)
{
char blk[512], tmp[512];
struct S *s = (struct S*) blk;
struct H *h;
getblk(blk);
if (s->a || !(h = gethdr(tmp)) || s->a != h->d) {
#ifdef BUG
printf("%d\n", s->b);
#endif
if (s->a)
printf("s->a = %d\n", s->a);
else if (!h)
printf("!h\n");
else
printf("h->d = %d\n", h->d);
}
}
$ gcc -O6 -Wall -c bogus2.c
$ gcc -DBUG -O6 -Wall -c bogus2.c
bogus2.c: In function ‘main’:
bogus2.c:42:17: warning: ‘h’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
else if (!h)
^
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
--- Comment #6 from lavr at ncbi dot nlm.nih.gov ---
That said, any function call within the outer "if()" but before the inner
"if()" would cause the warning, even if that call does not accept any pointers
(and thus cannot alias with local "s"). Modifying the code above to include
"fun()" in stead of "printf()", same issue results:
...
void fun(int i)
{
srand(i);
}
int main(void)
{
char blk[512], tmp[512];
struct S *s = (struct S*) blk;
struct H *h;
getblk(blk);
if (s->a || !(h = gethdr(tmp)) || s->a != h->d) {
#ifdef BUG
fun(s->b);
#endif
...
$ gcc -DBUG -O6 -Wall -c bogus2.c
bogus2.c: In function ‘main’:
bogus2.c:47:17: warning: ‘h’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
else if (!h)
^
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 David Malcolm changed: What|Removed |Added Status|REOPENED|ASSIGNED CC||dmalcolm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #26 from David Malcolm --- Created attachment 45674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45674&action=edit Work-in-progress patch for a new warning for this (for GCC 10 stage 1) (I plan to post this to the mailing list once gcc 10 stage 1 opens)
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 David Malcolm changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/89283] [8/9 Regression] ICE: Segmentation fault (in stmt_could_throw_1_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89283 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-12 CC||msebor at gcc dot gnu.org Known to work||7.3.0 Ever confirmed|0 |1 Known to fail||8.2.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed with no command line options. Bisection points to r247495: r247495 | rguenth | 2017-05-02 08:43:47 -0400 (Tue, 02 May 2017) | 24 lines 2017-05-02 Richard Biener * common.opt (fstrict-overflow): Alias negative to fwrapv. * doc/invoke.texi (fstrict-overflow): Remove all traces of -fstrict-overflow documentation. * tree.h (TYPE_OVERFLOW_UNDEFINED): Do not test flag_strict_overflow. (POINTER_TYPE_OVERFLOW_UNDEFINED): Test !flag_wrapv instead of flag_strict_overflow. * ipa-inline.c (can_inline_edge_p): Do not test flag_strict_overflow. * lto-opts.c (lto_write_options): Do not stream it. * lto-wrapper.c (merge_and_complain): Do not handle it. * opts.c (default_options_table): Do not set -fstrict-overflow. (finish_options): Likewise do not clear it when sanitizing. * simplify-rtx.c (simplify_const_relational_operation): Do not test flag_strict_overflow.
[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|rtl-optimization|middle-end Target Milestone|--- |8.3 --- Comment #11 from Richard Biener --- Needs more investigation (ignore my previous comment - main() is not really relevant here). This is a very recent regression on the branch. You can do -fdisable-tree-ealias and still get the failure but less early IL changes when comparing to -fno-tree-pta.
[Bug rtl-optimization/89310] New: Poor code generation returning float field from a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
Bug ID: 89310
Summary: Poor code generation returning float field from a
struct
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The following test case shows poor code generation on powerpc64le-linux:
bergner@pike:~/gcc/BUGS/PR88845$ cat struct.i
struct s {
int i;
float f;
};
float
foo (struct s arg)
{
return arg.f;
}
bergner@pike:~/gcc/BUGS/PR88845$ gcc -O2 -S struct.i
bergner@pike:~/gcc/BUGS/PR88845$ cat struct.s
foo:
srdi 3,3,32
sldi 9,3,32
mtvsrd 1,9
xscvspdpn 1,1
blr
The srdi followed by a sldi could be replaced with a simple: rldicr 9,3,0,31
[Bug c++/89311] New: Brace initialization needlessly invokes destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89311
Bug ID: 89311
Summary: Brace initialization needlessly invokes destructor
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raphael.kubo.da.costa at intel dot com
Target Milestone: ---
This is related to bug 85552 and bug 57082 as far as I can see.
GCC and ICC fail to compile this (I'm using -std=gnu++14), whereas MSVC and
clang accept it:
#include
template
struct S {
~S() {
for (size_t i = 0; i < sources_.size(); ++i)
sources_[i]->frob();
}
private:
std::vector sources_;
};
class C;
struct T {
S s_{};
};
: In instantiation of 'S::~S() [with T = C]':
:16:11: required from here
:7:20: error: invalid use of incomplete type 'class C'
7 | sources_[i]->frob();
| ~^~~~
:13:7: note: forward declaration of 'class C'
13 | class C;
| ^
which ends up requiring C to be fully declared before it can be used in T.
I think https://bugs.llvm.org/show_bug.cgi?id=39363#c8 touches upon this in
"The list-initialization case does not potentially-invoke the destructor in
C++11 or C++14 either (unlike non-list copy-initialization, list-initialization
directly executes a constructor on the destination object even in C++11, and as
a result there is no temporary object created to trigger the potential
invocation of a destructor). Clang gets that case right, but GCC has another
bug there".
[Bug rtl-optimization/89310] Poor code generation returning float field from a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #1 from Peter Bergner ---
Before combine, we have the following rtl:
(insn # # # 2 (set (reg/v:DI 122 [ argD.2825 ])
(reg:DI 3 3 [ argD.2825 ])) "struct.i":8:1# {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 3 3 [ argD.2825 ])
(nil)))
(note # # # 2 NOTE_INSN_FUNCTION_BEG)
(insn # # # 2 (parallel [
(set (reg:DI 124)
(ashiftrt:DI (reg/v:DI 122 [ argD.2825 ])
(const_int 32 [0x20])))
(clobber (reg:DI 76 ca))
]) "struct.i":9:13# {ashrdi3}
(expr_list:REG_DEAD (reg/v:DI 122 [ argD.2825 ])
(expr_list:REG_UNUSED (reg:DI 76 ca)
(nil
(insn # # # 2 (set (reg:SI 125)
(subreg:SI (reg:DI 124) 0)) "struct.i":9:13# {*movsi_internal1}
(expr_list:REG_DEAD (reg:DI 124)
(nil)))
(insn # # # 2 (parallel [
(set (reg:SF 121 [ ])
(unspec:SF [
(reg:SI 125)
] UNSPEC_SF_FROM_SI))
(clobber (scratch:DI))
]) "struct.i":9:13# {movsf_from_si}
(expr_list:REG_DEAD (reg:SI 125)
(nil)))
after combine, we get a strange paradoxical subreg:
(insn # # # 2 (set (reg:DI 126)
(reg:DI 3 3 [ argD.2825 ])) "struct.i":8:1# {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 3 3 [ argD.2825 ])
(nil)))
(insn # # # 2 (set (subreg:DI (reg:SI 125) 0)
(lshiftrt:DI (reg:DI 126)
(const_int 32 [0x20]))) "struct.i":9:13# {lshrdi3}
(expr_list:REG_DEAD (reg:DI 126)
(nil)))
(insn # # # 2 (parallel [
(set (reg/i:SF 33 1)
(unspec:SF [
(reg:SI 125)
] UNSPEC_SF_FROM_SI))
(clobber (scratch:DI))
]) "struct.i":10:1# {movsf_from_si}
(expr_list:REG_DEAD (reg:SI 125)
(nil)))
LRA cleans things up a bit to:
(insn # # # 2 (set (reg:DI 3 3 [125])
(lshiftrt:DI (reg:DI 3 3 [126])
(const_int 32 [0x20]))) "struct.i":9:13# {lshrdi3}
(nil))
(insn # # # 2 (parallel [
(set (reg/i:SF 33 1)
(unspec:SF [
(reg:SI 3 3 [125])
] UNSPEC_SF_FROM_SI))
(clobber (reg:DI 9 9 [127]))
]) "struct.i":10:1# {movsf_from_si}
(nil))
and then split2 creates the shift followed by shift:
insn # # # 2 (set (reg:DI 3 3 [125])
(lshiftrt:DI (reg:DI 3 3 [126])
(const_int 32 [0x20]))) "struct.i":9:13# {lshrdi3}
(nil))
(insn # # # 2 (set (reg:DI 9 9 [127])
(ashift:DI (reg:DI 3 3)
(const_int 32 [0x20]))) "struct.i":10:1# {ashldi3}
(nil))
(insn # # # 2 (set (reg/i:SF 33 1)
(unspec:SF [
(reg:DI 9 9 [127])
] UNSPEC_P8V_MTVSRD)) "struct.i":10:1# {p8_mtvsrd_sf}
(nil))
(insn # # # 2 (set (reg/i:SF 33 1)
(unspec:SF [
(reg/i:SF 33 1)
] UNSPEC_VSX_CVSPDPN)) "struct.i":10:1# {vsx_xscvspdpn_directmove}
(nil))
Is the paradoxical subreg from combine at fault here???
[Bug c/89312] New: snprintf warning is unparsable and not confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89312
Bug ID: 89312
Summary: snprintf warning is unparsable and not confusing
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Target Milestone: ---
Gcc 7 has a new warning:
partman.c:1908:12: error: ' (' directive output may be truncated writing 2
bytes into a region of size between 1 and 255 [-Werror=format-truncation=]
"%s (%s, %s-%d)",
^~
I am not a native speaker so this may be a lanugage barrirer, but I completely
fail to parse what it is trying to tell me here.
Obviously as I am using snprintf I am aware that truncation of the output could
happen (and happy with it). There is no point in gcc warning about this
(different to cases like strncpy truncation). The function is standard defined
and safe, why warn at all here?
[Bug c/89313] New: [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
Bug ID: 89313
Summary: [9 Regression] ICE in process_alt_operands, at
lra-constraints.c:2962
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20180930 and 20181007 :
$ cat z1.c
long f (long a);
long g (void)
{
register long z asm ("rax");
asm ("foo %0, %1, %1" : "=&r" (z) : "r" (f), "0" (f));
return z;
}
$ gcc-9-20190210 -c z1.c -O0
z1.c: Assembler messages:
z1.c:5: Error: no such instruction: `foo %rax,%rdx,%rdx'
$ gcc-9-20190210 -c z1.c -O2
z1.c: In function 'g':
z1.c:7:1: error: unable to generate reloads for impossible constraints:
7 | }
| ^
(insn 7 16 15 2 (parallel [
(set (reg/v:DI 0 ax [ z ])
(asm_operands:DI ("foo %0, %1, %1") ("=&r") 0 [
(reg/v:DI 0 ax [ z ]) repeated x2
]
[
(asm_input:DI ("r") z1.c:5)
(asm_input:DI ("0") z1.c:5)
]
[] z1.c:5))
(clobber (reg:CC 17 flags))
]) "z1.c":5:3 -1
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
during RTL pass: reload
z1.c:7:1: internal compiler error: in process_alt_operands, at
lra-constraints.c:2962
0x5aa7c0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x93ac40 process_alt_operands
../../gcc/lra-constraints.c:2961
0x93d4bb curr_insn_transform
../../gcc/lra-constraints.c:3922
0x93fe8e lra_constraints(bool)
../../gcc/lra-constraints.c:4942
0x92e454 lra(_IO_FILE*)
../../gcc/lra.c:2461
0x8e9ff1 do_reload
../../gcc/ira.c:5516
0x8e9ff1 execute
../../gcc/ira.c:5700
[Bug c/89314] New: ICE in wide_int_to_tree_1, at tree.c:1561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89314
Bug ID: 89314
Summary: ICE in wide_int_to_tree_1, at tree.c:1561
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least gcc-5 :
$ cat z1.c
extern __SIZE_TYPE__ strlen (const float *);
void foo (char *s)
{
if (strlen(s) > 0)
return;
}
$ gcc-9-20190210 -c z1.c
z1.c: In function 'foo':
z1.c:4:14: warning: passing argument 1 of 'strlen' from incompatible pointer
type [-Wincompatible-pointer-types]
4 | if (strlen(s) > 0)
| ^
| |
| char *
z1.c:1:30: note: expected 'const float *' but argument is of type 'char *'
1 | extern __SIZE_TYPE__ strlen (const float *);
| ^
z1.c:4:3: internal compiler error: in wide_int_to_tree_1, at tree.c:1561
4 | if (strlen(s) > 0)
| ^~
0xf0c3b3 wide_int_to_tree_1
../../gcc/tree.c:1561
0xf0cab8 wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
../../gcc/tree.c:1686
0xf0cab8 build_int_cst(tree_node*, poly_int<1u, long>)
../../gcc/tree.c:1355
0x8e5bdd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:10755
0x8e9f4a fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12350
0x1195677 generic_simplify_76
.../gcc/generic-match.c:3439
0x11a0df0 generic_simplify_GT_EXPR
.../gcc/generic-match.c:38239
0x11d683d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.../gcc/generic-match.c:52818
0x8e0aad fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9378
0x8e9f4a fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12350
0x693b79 c_fully_fold_internal
../../gcc/c/c-fold.c:370
0x695877 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x6734ec c_parser_condition
../../gcc/c/c-parser.c:5640
0x673587 c_parser_paren_condition
../../gcc/c/c-parser.c:5658
0x68493a c_parser_if_statement
../../gcc/c/c-parser.c:5837
0x68493a c_parser_statement_after_labels
../../gcc/c/c-parser.c:5469
0x68618e c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5148
0x686916 c_parser_compound_statement
../../gcc/c/c-parser.c:4982
0x6881fb c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2354
0x6907c3 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
[Bug c++/89315] New: Cannot convert to std::initializer_list - fails with gcc9 works with gcc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89315
Bug ID: 89315
Summary: Cannot convert to std::initializer_list - fails with
gcc9 works with gcc8
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 45675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45675&action=edit
Soruce that works with gcc8 fails with gcc9
The attached code compiles with:
g++ --version
g++ (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6)
but fails with
/opt/gcc/gcc-9/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc-9/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-9/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gcc/gcc-9
--enable-checking=release --enable-languages=c,c++
/opt/gcc/gcc-9/bin/g++ -c bug4.cpp
bug4.cpp: In instantiation of ‘void n< >::m_fn1()
[with = void]’:
bug4.cpp:17:22: required from here
bug4.cpp:13:24: error: cannot convert ‘const bar*’ to
‘std::initializer_list’
13 | void m_fn1() { i{{}}; }
|^
bug4.cpp:4:9: note: initializing argument 1 of
‘bar::bar(std::initializer_list, int)’
4 | bar(std::initializer_list, int = int());
| ^~
[Bug rtl-optimization/89310] Poor code generation returning float field from a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-12 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- This is caused by a split after reload. The insns that are split to do not get all the early RTL optimisations. Late splits should be avoided. Why does this use mtvsrd instead opf mtvsrw[az]?
[Bug c++/89316] New: ICE in gen_reg_rtx, at emit-rtl.c:1155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Bug ID: 89316
Summary: ICE in gen_reg_rtx, at emit-rtl.c:1155
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Starting with gcc-8 and options -fsplit-stack -mforce-indirect-call;
affects several test cases, e.g. :
$ cat first-global.C
struct foo { foo (); };
foo foobar;
$ g++-9-20190210 -c first-global.C
$ g++-9-20190210 -c first-global.C -fsplit-stack
$
$ g++-9-20190210 -c first-global.C -fsplit-stack -mforce-indirect-call
during RTL pass: pro_and_epilogue
first-global.C: In function 'void
__static_initialization_and_destruction_0(int, int)':
first-global.C:2:11: internal compiler error: in gen_reg_rtx, at
emit-rtl.c:1155
2 | foo foobar;
| ^
0x8bdda5 gen_reg_rtx(machine_mode)
../../gcc/emit-rtl.c:1155
0x8d1ffe copy_to_mode_reg(machine_mode, rtx_def*)
../../gcc/explow.c:622
0xe825b4 ix86_expand_call(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
bool)
../../gcc/config/i386/i386.c:28304
0xe831ba ix86_expand_split_stack_prologue()
../../gcc/config/i386/i386.c:14763
0x10bfa9a gen_split_stack_prologue()
../../gcc/config/i386/i386.md:13199
0xe4e548 target_gen_split_stack_prologue
../../gcc/config/i386/i386.md:12962
0x93a0c1 make_split_prologue_seq
../../gcc/function.c:5714
0x93a35a thread_prologue_and_epilogue_insns()
../../gcc/function.c:5850
0x93a952 rest_of_handle_thread_prologue_and_epilogue
../../gcc/function.c:6342
0x93a952 execute
../../gcc/function.c:6384
[Bug c++/89317] New: Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
Bug ID: 89317
Summary: Ineffective code from std::copy
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
gcc produces ineffective code when std::copy is used to copy data. For test I
created my own version of std::copy and this version is optimized properly.
Compiles using g++ (GCC-Explorer-Build) 9.0.1 20190211 (experimental)
Options: -O3 -std=c++11 -march=skylake
[code]
#include
#include
#define Size 8
class Test
{
public:
void test1(void*__restrict ptr);
void test2(void*__restrict ptr);
private:
int16_t data1[Size];
int16_t data2[Size];
};
template
void mycopy(T1 begin, T1 end, T2 dest)
{
while (begin != end)
{
*dest = *begin;
++dest;
++begin;
}
}
void Test::test1(void*__restrict ptr)
{
uint16_t* p = (uint16_t*)ptr;
std::copy(data1, data1 + Size, p);
p += Size;
std::copy(data2, data2 + Size, p);
}
void Test::test2(void*__restrict ptr)
{
int16_t* p = (int16_t*)ptr;
mycopy(data1, data1 + Size, p);
p += Size;
mycopy(data2, data2 + Size, p);
}
[/code]
[asm]
Test::test1(void*):
movzx eax, WORD PTR [rdi]
mov edx, 16
mov WORD PTR [rsi], ax
movzx eax, WORD PTR [rdi+2]
add rsi, 16
mov WORD PTR [rsi-14], ax
movzx eax, WORD PTR [rdi+4]
mov WORD PTR [rsi-12], ax
movzx eax, WORD PTR [rdi+6]
mov WORD PTR [rsi-10], ax
movzx eax, WORD PTR [rdi+8]
mov WORD PTR [rsi-8], ax
movzx eax, WORD PTR [rdi+10]
mov WORD PTR [rsi-6], ax
movzx eax, WORD PTR [rdi+12]
mov WORD PTR [rsi-4], ax
movzx eax, WORD PTR [rdi+14]
mov WORD PTR [rsi-2], ax
mov rax, rdx
sar rax
testrdx, rdx
jle .L69
movzx edx, WORD PTR [rdi+16]
mov WORD PTR [rsi], dx
cmp rax, 1
je .L69
movzx edx, WORD PTR [rdi+18]
mov WORD PTR [rsi+2], dx
cmp rax, 2
je .L69
movzx edx, WORD PTR [rdi+20]
mov WORD PTR [rsi+4], dx
cmp rax, 3
je .L69
movzx edx, WORD PTR [rdi+22]
mov WORD PTR [rsi+6], dx
cmp rax, 4
je .L69
movzx edx, WORD PTR [rdi+24]
mov WORD PTR [rsi+8], dx
cmp rax, 5
je .L69
movzx edx, WORD PTR [rdi+26]
mov WORD PTR [rsi+10], dx
cmp rax, 6
je .L69
movzx edx, WORD PTR [rdi+28]
mov WORD PTR [rsi+12], dx
cmp rax, 7
je .L69
movzx edx, WORD PTR [rdi+30]
mov WORD PTR [rsi+14], dx
cmp rax, 8
je .L69
movzx edx, WORD PTR [rdi+32]
mov WORD PTR [rsi+16], dx
cmp rax, 9
je .L69
movzx edx, WORD PTR [rdi+34]
mov WORD PTR [rsi+18], dx
cmp rax, 10
je .L69
movzx edx, WORD PTR [rdi+36]
mov WORD PTR [rsi+20], dx
cmp rax, 11
je .L69
movzx edx, WORD PTR [rdi+38]
mov WORD PTR [rsi+22], dx
cmp rax, 12
je .L69
movzx edx, WORD PTR [rdi+40]
mov WORD PTR [rsi+24], dx
cmp rax, 13
je .L69
movzx edx, WORD PTR [rdi+42]
mov WORD PTR [rsi+26], dx
cmp rax, 14
je .L69
movzx eax, WORD PTR [rdi+44]
mov WORD PTR [rsi+28], ax
.L69:
ret
Test::test2(void*):
vmovdqu xmm0, XMMWORD PTR [rdi]
vmovups XMMWORD PTR [rsi], xmm0
vmovdqu xmm1, XMMWORD PTR [rdi+16]
vmovups XMMWORD PTR [rsi+16], xmm1
ret
[/asm]
[Bug tree-optimization/88713] Vectorized code slow vs. flang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #54 from Chris Elrod --- I commented elsewhere, but I built trunk a few days ago with H.J.Lu's patches (attached here) and Thomas Koenig's inlining patches. With these patches, g++ and all versions of the Fortran code produced excellent asm, and the code performed excellently in benchmarks. Once those are merged, the problems reported here will be solved. I saw Thomas Koenig's packing changes will wait for gcc-10. What about H.J.Lu's fixes to rsqrt and allowing FMA use in those sections?
[Bug c++/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-12 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed on trunk and gcc-8. It's failing this assertion: 1155 gcc_assert (can_create_pseudo_p ()); since: (gdb) p reload_completed $3 = 1
