[Bug tree-optimization/84204] [8/9 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84204 Arseny Solokha changed: What|Removed |Added Summary|[8 Regression] [graphite] |[8/9 Regression] [graphite] |ICE in set_codegen_error, |ICE in set_codegen_error, |at |at |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple. |c:206 |c:206 Known to fail||9.0 --- Comment #9 from Arseny Solokha --- It's [8/9 Regression], then.
[Bug rtl-optimization/87596] [9 Regression] ICE: Segmentation fault (in spill_hard_reg_in_range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87596 --- Comment #7 from Arseny Solokha --- Should we close this PR now?
[Bug c++/87680] New: Small program produces 400 meg .s file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680
Bug ID: 87680
Summary: Small program produces 400 meg .s file
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu at kosak dot com
Target Milestone: ---
This small program takes over a minute to compile and produces a 160 meg object
file. sizeof(Bar) is large and it looks like the compiler wants to write down a
precompiled version of it to the object file for the benefit of Bar's
constructor. There are no static variables or anything like that so the object
file really should be modest in size.
% cat test.cc
constexpr int size = 1000;
class Foo {
int a = 10;
int b = 11;
int c = 12;
int d = 13;
};
class Bar {
Foo foo[size];
};
void somefunc(const Bar *);
int main() {
Bar *bar = new Bar();
somefunc(bar);
}
% time g++ -O2 -c test.cc
real1m9.696s
user1m6.486s
sys 0m2.806s
% ls -l test.o
-rw-rw-r-- 1 kosak kosak 160001760 Oct 22 01:41 test.o
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #19 from Harald van Dijk ---
(In reply to Segher Boessenkool from comment #18)
> (In reply to Harald van Dijk from comment #15)
> > (In reply to Segher Boessenkool from comment #10)
> > > The initialisation (the call to f1) could have a side effect, but the
> > > a==1 case skips that. GCC is right to warn here in my opinion.
>
> > And warnings that are likely to trigger on
> > perfectly valid code that behaves exactly as the author intended shouldn't
> > be included in -Wall, per your own comment.
>
> No, that is not what I said. *All* warnings are likely to trigger on valid
> code, after all. I said "frequent false positives".
Please re-read what I said. I didn't just say valid code, I said valid code
that behaves exactly as the author intended, or in other words code where the
fact that the initialisation is skipped over does not point to any problem, or
in other words a false positive.
I'm only at the start of a rebuild to see how commonly this warning will be
triggered, but I have found more false positives already almost immediately:
alsa-lib-1.1.7:
setup.c: In function 'snd_config_get_ctl_elem_value':
setup.c:361:5: error: jump skips variable initialization
[-Werror=jump-misses-init]
goto _bad_content;
^~~~
setup.c:313:4: note: label '_bad_content' defined here
_bad_content:
^~~~
setup.c:311:17: note: 'idx' declared here
unsigned int idx = 0;
^~~
(and more)
anjuta-3.28.0:
jsparse.c: In function 'print_node':
jsparse.c:49:4: error: switch jumps over variable initialization
[-Werror=jump-misses-init]
case TOK_RC:
^~~~
jsparse.c:32:4: note: switch starts here
switch ((JSTokenType)node->pn_type)
^~
jsparse.c:43:9: note: 'k' declared here
int k = 0;
^
(and more)
at-spi2-core-2.30.0:
../at-spi2-core-2.30.0/dbind/dbind-any.c: In function 'dbind_any_demarshal':
../at-spi2-core-2.30.0/dbind/dbind-any.c:642:5: error: switch jumps over
variable initialization [-Werror=jump-misses-init]
case DBUS_TYPE_VARIANT:
^~~~
../at-spi2-core-2.30.0/dbind/dbind-any.c:541:5: note: switch starts here
switch (**type) {
^~
../at-spi2-core-2.30.0/dbind/dbind-any.c:618:21: note: 'offset' declared here
int offset = 0, stralign;
^~
(and more)
busybox-1.29.3:
archival/bbunzip.c: In function 'bbunpack':
archival/bbunzip.c:68:6: error: jump skips variable initialization
[-Werror=jump-misses-init]
goto free_name;
^~~~
archival/bbunzip.c:183:2: note: label 'free_name' defined here
free_name:
^
archival/bbunzip.c:139:10: note: 'del' declared here
char *del = new_name;
^~~
In file included from archival/bzip2.c:101:
archival/libarchive/bz/compress.c: In function 'generateMTFValues':
archival/libarchive/bz/compress.c:286:3: error: jump skips variable
initialization [-Werror=jump-misses-init]
goto process_zPend; /* "process it and come back here" */
^~~~
archival/libarchive/bz/compress.c:251:2: note: label 'process_zPend' defined
here
process_zPend:
^
archival/libarchive/bz/compress.c:235:11: note: 'll_i' declared here
uint8_t ll_i = ll_i; /* gcc 4.3.1 thinks it may be used w/o init */
^~~~
cargo-vendor-0.1.15:
/h/cargo-vendor-src-0.1.15/vendor/libssh2-sys/libssh2/src/packet.c: In function
'_libssh2_packet_add':
/h/cargo-vendor-src-0.1.15/vendor/libssh2-sys/libssh2/src/packet.c:454:9:
error: jump skips variable initialization [-Werror=jump-misses-init]
goto libssh2_packet_add_jump_point5;
^~~~
/h/cargo-vendor-src-0.1.15/vendor/libssh2-sys/libssh2/src/packet.c:588:19:
note: label 'libssh2_packet_add_jump_point5' defined here
libssh2_packet_add_jump_point5:
^~
/h/cargo-vendor-src-0.1.15/vendor/libssh2-sys/libssh2/src/packet.c:574:31:
note: 'want_reply' declared here
unsigned char want_reply=0;
^~
(and more)
chromium-71.0.3578.10:
../../third_party/angle/third_party/vulkan-loader/src/loader/trampoline.c: In
function 'vkEnumeratePhysicalDevices':
../../third_party/angle/third_party/vulkan-loader/src/loader/trampoline.c:658:9:
error: jump skips variable initialization [-Werror=jump-misses-init]
goto out;
^~~~
../../third_party/angle/third_party/vulkan-loader/src/loader/trampoline.c:696:1:
note: label 'out' defined here
out:
^~~
../../third_party/angle/third_party/vulkan-loader/src/loader/trampoline.c:671:14:
note: 'setup_res' declared here
VkResult setup_res = setupLoaderTrampPhysDevs(instance);
^
(and more)
efivar-36:
efivarfs.c: In function 'efivarfs_get_variable_size':
efivarfs.c:182:3: error: jump skips variable initialization
[-Werror=jump-misses-init]
goto err;
^~~~
efivarfs.c:195:1: note: label 'err' defined here
err:
^~~
efivarfs.c:185:14:
[Bug libstdc++/87679] New: std::this_thread::sleep_until sleeps too much for clocks faster than system_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87679
Bug ID: 87679
Summary: std::this_thread::sleep_until sleeps too much for
clocks faster than system_clock
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ddomenichelli at drdanz dot it
Target Milestone: ---
I have a simulated clock that is not steady and runs faster than the actual
system clock.
In libstdc++ 8.2, std::this_thread::sleep_until implementation for not-steady
clocks is something like this:
auto __now = _Clock::now();
while (__now < __atime)
{
sleep_for(__atime - __now);
__now = _Clock::now();
}
where sleep_for puts the thread to sleep for the expected number of seconds,
but using the system clock.
This works if _Clock is the system_clock or it is slower than system_clock, but
it will always sleep too much if it is faster. I'm not sure if this is a real
bug, since I believe that the standard that the call should return after at
least the requested time, but for sure it is still not optimal.
The workaround is to specialize std::this_thread::sleep_until for my clock, but
I thought it was worth reporting the problem...
Perhaps c++ "Clock" requirement should have a "real time factor" (that is not
necessarily constant during the execution), that can be used to optimize
sleep_until? (This would be good both for faster and slower clocks).
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #18 from Segher Boessenkool --- (In reply to Harald van Dijk from comment #15) > (In reply to Segher Boessenkool from comment #10) > > The initialisation (the call to f1) could have a side effect, but the > > a==1 case skips that. GCC is right to warn here in my opinion. > And warnings that are likely to trigger on > perfectly valid code that behaves exactly as the author intended shouldn't > be included in -Wall, per your own comment. No, that is not what I said. *All* warnings are likely to trigger on valid code, after all. I said "frequent false positives".
[Bug target/87678] New: Redundant vmovss with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
Bug ID: 87678
Summary: Redundant vmovss with -fPIC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: i386
[hjl@gnu-efi-2 broadcast-1]$ cat y.c
#include
float
foo (__m128 x)
{
return ((__v4sf) x)[0] * 2.387f;
}
[hjl@gnu-efi-2 broadcast-1]$ gcc -O2 y.c -mfpmath=sse -fpic -m32 -S -mavx
c[hjl@gnu-efi-2 broadcast-1]$ cat y.s
.file "y.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB5086:
.cfi_startproc
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
subl$28, %esp
.cfi_def_cfa_offset 32
vmovss .LC0@GOTOFF(%eax), %xmm1
This isn't needed.
vmulss %xmm1, %xmm0, %xmm0
vmovss %xmm0, 12(%esp)
flds12(%esp)
addl$28, %esp
.cfi_def_cfa_offset 4
ret
.cfi_endproc
.LFE5086:
.size foo, .-foo
We should replace
vmovss .LC0@GOTOFF(%eax), %xmm1
vmulss %xmm1, %xmm0, %xmm0
with
vmulss .LC0@GOTOFF(%eax), %xmm0, %xmm0
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #11 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Oct 21 20:30:06 2018 New Revision: 265359 URL: https://gcc.gnu.org/viewcvs?rev=265359=gcc=rev Log: i386: Update AVX512 FMSUB/FNMADD/FNMSUB tests Update AVX512 tests to test the newly added FMSUB, FNMADD and FNMSUB builtin functions. PR target/72782 * gcc.target/i386/avx-1.c (__builtin_ia32_vfmsubpd512_mask): New. (__builtin_ia32_vfmsubpd512_maskz): Likewise. (__builtin_ia32_vfmsubps512_mask): Likewise. (__builtin_ia32_vfmsubps512_maskz): Likewise. (__builtin_ia32_vfnmaddpd512_mask3): Likewise. (__builtin_ia32_vfnmaddpd512_maskz): Likewise. (__builtin_ia32_vfnmaddps512_mask3): Likewise. (__builtin_ia32_vfnmaddps512_maskz): Likewise. (__builtin_ia32_vfnmsubpd512_maskz): Likewise. (__builtin_ia32_vfnmsubps512_maskz): Likewise. * testsuite/gcc.target/i386/sse-13.c (__builtin_ia32_vfmsubpd512_mask): Likewise. (__builtin_ia32_vfmsubpd512_maskz): Likewise. (__builtin_ia32_vfmsubps512_mask): Likewise. (__builtin_ia32_vfmsubps512_maskz): Likewise. (__builtin_ia32_vfnmaddpd512_mask3): Likewise. (__builtin_ia32_vfnmaddpd512_maskz): Likewise. (__builtin_ia32_vfnmaddps512_mask3): Likewise. (__builtin_ia32_vfnmaddps512_maskz): Likewise. (__builtin_ia32_vfnmsubpd512_maskz): Likewise. (__builtin_ia32_vfnmsubps512_maskz): Likewise. * testsuite/gcc.target/i386/sse-23.c (__builtin_ia32_vfmsubpd512_mask): Likewise. (__builtin_ia32_vfmsubpd512_maskz): Likewise. (__builtin_ia32_vfmsubps512_mask): Likewise. (__builtin_ia32_vfmsubps512_maskz): Likewise. (__builtin_ia32_vfnmaddpd512_mask3): Likewise. (__builtin_ia32_vfnmaddpd512_maskz): Likewise. (__builtin_ia32_vfnmaddps512_mask3): Likewise. (__builtin_ia32_vfnmaddps512_maskz): Likewise. (__builtin_ia32_vfnmsubpd512_maskz): Likewise. (__builtin_ia32_vfnmsubps512_maskz): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx-1.c trunk/gcc/testsuite/gcc.target/i386/sse-13.c trunk/gcc/testsuite/gcc.target/i386/sse-23.c
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #10 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Oct 21 20:28:56 2018 New Revision: 265358 URL: https://gcc.gnu.org/viewcvs?rev=265358=gcc=rev Log: i386: Enable AVX512 memory broadcast for FNMSUB Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for FNMSUB operations. In order to support AVX512 memory broadcast for FNMSUB, FNMSUB builtin functions are also added, instead of passing the negated value to FMA builtin functions. gcc/ PR target/72782 * config/i386/avx512fintrin.h (_mm512_fnmsub_round_pd): Use __builtin_ia32_vfnmsubpd512_mask. (_mm512_mask_fnmsub_round_pd): Likewise. (_mm512_fnmsub_pd): Likewise. (_mm512_mask_fnmsub_pd): Likewise. (_mm512_maskz_fnmsub_round_pd): Use __builtin_ia32_vfnmsubpd512_maskz. (_mm512_maskz_fnmsub_pd): Likewise. (_mm512_fnmsub_round_ps): Use __builtin_ia32_vfnmsubps512_mask. (_mm512_mask_fnmsub_round_ps): Likewise. (_mm512_fnmsub_ps): Likewise. (_mm512_mask_fnmsub_ps): Likewise. (_mm512_maskz_fnmsub_round_ps): Use __builtin_ia32_vfnmsubps512_maskz. (_mm512_maskz_fnmsub_ps): Likewise. * config/i386/avx512vlintrin.h (_mm256_mask_fnmsub_pd): Use __builtin_ia32_vfnmsubpd256_mask. (_mm256_maskz_fnmsub_pd): Use __builtin_ia32_vfnmsubpd256_maskz. (_mm_mask_fnmsub_pd): Use __builtin_ia32_vfmaddpd128_mask (_mm_maskz_fnmsub_pd): Use __builtin_ia32_vfnmsubpd128_maskz. (_mm256_mask_fnmsub_ps): Use __builtin_ia32_vfnmsubps256_mask. (_mm256_mask_fnmsub_ps): Use __builtin_ia32_vfnmsubps256_mask. (_mm256_maskz_fnmsub_ps): Use __builtin_ia32_vfnmsubps256_maskz. (_mm_mask_fnmsub_ps): Use __builtin_ia32_vfnmsubps128_mask. (_mm_maskz_fnmsub_ps): Use __builtin_ia32_vfnmsubps128_maskz. * config/i386/fmaintrin.h (_mm_fnmsub_pd): Use __builtin_ia32_vfnmsubpd. (_mm256_fnmsub_pd): Use __builtin_ia32_vfnmsubpd256. (_mm_fnmsub_ps): Use __builtin_ia32_vfnmsubps. (_mm256_fnmsub_ps): Use __builtin_ia32_vfnmsubps256. (_mm_fnmsub_sd): Use __builtin_ia32_vfnmsubsd3. (_mm_fnmsub_ss): Use __builtin_ia32_vfnmsubss3. * config/i386/i386-builtin.def: Add __builtin_ia32_vfnmsubpd256_mask, __builtin_ia32_vfnmsubpd256_maskz, __builtin_ia32_vfnmsubpd128_mask, __builtin_ia32_vfnmsubpd128_maskz, __builtin_ia32_vfnmsubps256_mask, __builtin_ia32_vfnmsubps256_maskz, __builtin_ia32_vfnmsubps128_mask, __builtin_ia32_vfnmsubps128_maskz, __builtin_ia32_vfnmsubpd512_mask, __builtin_ia32_vfnmsubpd512_maskz, __builtin_ia32_vfnmsubps512_mask, __builtin_ia32_vfnmsubps512_maskz, __builtin_ia32_vfnmsubss3, __builtin_ia32_vfnmsubsd3, __builtin_ia32_vfnmsubps, __builtin_ia32_vfnmsubpd, __builtin_ia32_vfnmsubps256 and. __builtin_ia32_vfnmsubpd256. * config/i386/sse.md (fma4i_fnmsub_): New. (_fnmsub__maskz): Likewise. (*fma_fnmsub__bcst_1): Likewise. (*fma_fnmsub__bcst_2): Likewise. (*fma_fnmsub__bcst_3): Likewise. (fmai_vmfnmsub_): Likewise. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512f-fnmsub-df-zmm-1.c: New test. * gcc.target/i386/avx512f-fnmsub-sf-zmm-1.c: Likewise. * gcc.target/i386/avx512f-fnmsub-sf-zmm-2.c: Likewise. * gcc.target/i386/avx512f-fnmsub-sf-zmm-3.c: Likewise. * gcc.target/i386/avx512f-fnmsub-sf-zmm-4.c: Likewise. * gcc.target/i386/avx512f-fnmsub-sf-zmm-5.c: Likewise. * gcc.target/i386/avx512f-fnmsub-sf-zmm-6.c: Likewise. * gcc.target/i386/avx512f-fnmsub-sf-zmm-7.c: Likewise. * gcc.target/i386/avx512f-fnmsub-sf-zmm-8.c: Likewise. * gcc.target/i386/avx512vl-fnmsub-sf-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-fnmsub-sf-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-df-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-7.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmsub-sf-zmm-8.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-fnmsub-sf-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-fnmsub-sf-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avx512vlintrin.h trunk/gcc/config/i386/fmaintrin.h
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #9 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Oct 21 20:27:09 2018 New Revision: 265357 URL: https://gcc.gnu.org/viewcvs?rev=265357=gcc=rev Log: i386: Enable AVX512 memory broadcast for FNMADD Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for FNMADD operations. In order to support AVX512 memory broadcast for FNMADD, FNMADD builtin functions are also added, instead of passing the negated value to FMA builtin functions. gcc/ PR target/72782 * config/i386/avx512fintrin.h (_mm512_fnmadd_round_pd): Use __builtin_ia32_vfnmaddpd512_mask. (_mm512_mask_fnmadd_round_pd): Likewise. (_mm512_fnmadd_pd): Likewise. (_mm512_mask_fnmadd_pd): Likewise. (_mm512_maskz_fnmadd_round_pd): Use __builtin_ia32_vfnmaddpd512_maskz. (_mm512_maskz_fnmadd_pd): Likewise. (_mm512_fnmadd_round_ps): Use __builtin_ia32_vfnmaddps512_mask. (_mm512_mask_fnmadd_round_ps): Likewise. (_mm512_fnmadd_ps): Likewise. (_mm512_mask_fnmadd_ps): Likewise. (_mm512_maskz_fnmadd_round_ps): Use __builtin_ia32_vfnmaddps512_maskz. (_mm512_maskz_fnmadd_ps): Likewise. * config/i386/avx512vlintrin.h (_mm256_mask_fnmadd_pd): Use __builtin_ia32_vfnmaddpd256_mask. (_mm256_maskz_fnmadd_pd): Use __builtin_ia32_vfnmaddpd256_maskz. (_mm_mask_fnmadd_pd): Use __builtin_ia32_vfmaddpd128_mask (_mm_maskz_fnmadd_pd): Use __builtin_ia32_vfnmaddpd128_maskz. (_mm256_mask_fnmadd_ps): Use __builtin_ia32_vfnmaddps256_mask. (_mm256_mask_fnmadd_ps): Use __builtin_ia32_vfnmaddps256_mask. (_mm256_maskz_fnmadd_ps): Use __builtin_ia32_vfnmaddps256_maskz. (_mm_mask_fnmadd_ps): Use __builtin_ia32_vfnmaddps128_mask. (_mm_maskz_fnmadd_ps): Use __builtin_ia32_vfnmaddps128_maskz. * config/i386/fmaintrin.h (_mm_fnmadd_pd): Use __builtin_ia32_vfnmaddpd. (_mm256_fnmadd_pd): Use __builtin_ia32_vfnmaddpd256. (_mm_fnmadd_ps): Use __builtin_ia32_vfnmaddps. (_mm256_fnmadd_ps): Use __builtin_ia32_vfnmaddps256. (_mm_fnmadd_sd): Use __builtin_ia32_vfnmaddsd3. (_mm_fnmadd_ss): Use __builtin_ia32_vfnmaddss3. * config/i386/i386-builtin.def: Add __builtin_ia32_vfnmaddpd256_mask, __builtin_ia32_vfnmaddpd256_maskz, __builtin_ia32_vfnmaddpd128_mask, __builtin_ia32_vfnmaddpd128_maskz, __builtin_ia32_vfnmaddps256_mask, __builtin_ia32_vfnmaddps256_maskz, __builtin_ia32_vfnmaddps128_mask, __builtin_ia32_vfnmaddps128_maskz, __builtin_ia32_vfnmaddpd512_mask, __builtin_ia32_vfnmaddpd512_maskz, __builtin_ia32_vfnmaddps512_mask, __builtin_ia32_vfnmaddps512_maskz, __builtin_ia32_vfnmaddss3, __builtin_ia32_vfnmaddsd3, __builtin_ia32_vfnmaddps, __builtin_ia32_vfnmaddpd, __builtin_ia32_vfnmaddps256 and. __builtin_ia32_vfnmaddpd256. * config/i386/sse.md (fma4i_fnmadd_): New. (_fnmadd__maskz): Likewise. (*fma_fnmadd__bcst_1): Likewise. (*fma_fnmadd__bcst_2): Likewise. (*fma_fnmadd__bcst_3): Likewise. (fmai_vmfnmadd_): Likewise. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512f-fnmadd-df-zmm-1.c: New test. * gcc.target/i386/avx512f-fnmadd-sf-zmm-1.c: Likewise. * gcc.target/i386/avx512f-fnmadd-sf-zmm-2.c: Likewise. * gcc.target/i386/avx512f-fnmadd-sf-zmm-3.c: Likewise. * gcc.target/i386/avx512f-fnmadd-sf-zmm-4.c: Likewise. * gcc.target/i386/avx512f-fnmadd-sf-zmm-5.c: Likewise. * gcc.target/i386/avx512f-fnmadd-sf-zmm-6.c: Likewise. * gcc.target/i386/avx512f-fnmadd-sf-zmm-7.c: Likewise. * gcc.target/i386/avx512f-fnmadd-sf-zmm-8.c: Likewise. * gcc.target/i386/avx512vl-fnmadd-sf-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-fnmadd-sf-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-df-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-7.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fnmadd-sf-zmm-8.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-fnmadd-sf-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-fnmadd-sf-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avx512vlintrin.h trunk/gcc/config/i386/fmaintrin.h
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Oct 21 20:24:50 2018 New Revision: 265356 URL: https://gcc.gnu.org/viewcvs?rev=265356=gcc=rev Log: Enable AVX512 memory broadcast for FMSUB Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for FMSUB operations. In order to support AVX512 memory broadcast for FMSUB, FMSUB builtin functions are also added, instead of passing the negated value to FMA builtin functions. gcc/ PR target/72782 * config/i386/avx512fintrin.h (_mm512_fmsub_round_pd): Use __builtin_ia32_vfmsubpd512_mask. (_mm512_mask_fmsub_round_pd): Likewise. (_mm512_fmsub_pd): Likewise. (_mm512_mask_fmsub_pd): Likewise. (_mm512_maskz_fmsub_round_pd): Use __builtin_ia32_vfmsubpd512_maskz. (_mm512_maskz_fmsub_pd): Likewise. (_mm512_fmsub_round_ps): Use __builtin_ia32_vfmsubps512_mask. (_mm512_mask_fmsub_round_ps): Likewise. (_mm512_fmsub_ps): Likewise. (_mm512_mask_fmsub_ps): Likewise. (_mm512_maskz_fmsub_round_ps): Use __builtin_ia32_vfmsubps512_maskz. (_mm512_maskz_fmsub_ps): Likewise. * config/i386/avx512vlintrin.h (_mm256_mask_fmsub_pd): Use __builtin_ia32_vfmsubpd256_mask. (_mm256_maskz_fmsub_pd): Use __builtin_ia32_vfmsubpd256_maskz. (_mm_mask_fmsub_pd): Use __builtin_ia32_vfmaddpd128_mask (_mm_maskz_fmsub_pd): Use __builtin_ia32_vfmsubpd128_maskz. (_mm256_mask_fmsub_ps): Use __builtin_ia32_vfmsubps256_mask. (_mm256_mask_fmsub_ps): Use __builtin_ia32_vfmsubps256_mask. (_mm256_maskz_fmsub_ps): Use __builtin_ia32_vfmsubps256_maskz. (_mm_mask_fmsub_ps): Use __builtin_ia32_vfmsubps128_mask. (_mm_maskz_fmsub_ps): Use __builtin_ia32_vfmsubps128_maskz. * config/i386/fmaintrin.h (_mm_fmsub_pd): Use __builtin_ia32_vfmsubpd. (_mm256_fmsub_pd): Use __builtin_ia32_vfmsubpd256. (_mm_fmsub_ps): Use __builtin_ia32_vfmsubps. (_mm256_fmsub_ps): Use __builtin_ia32_vfmsubps256. (_mm_fmsub_sd): Use __builtin_ia32_vfmsubsd3. (_mm_fmsub_ss): Use __builtin_ia32_vfmsubss3. * config/i386/i386-builtin.def: Add __builtin_ia32_vfmsubpd256_mask, __builtin_ia32_vfmsubpd256_maskz, __builtin_ia32_vfmsubpd128_mask, __builtin_ia32_vfmsubpd128_maskz, __builtin_ia32_vfmsubps256_mask, __builtin_ia32_vfmsubps256_maskz, __builtin_ia32_vfmsubps128_mask, __builtin_ia32_vfmsubps128_maskz, __builtin_ia32_vfmsubpd512_mask, __builtin_ia32_vfmsubpd512_maskz, __builtin_ia32_vfmsubps512_mask, __builtin_ia32_vfmsubps512_maskz, __builtin_ia32_vfmsubss3, __builtin_ia32_vfmsubsd3, __builtin_ia32_vfmsubps, __builtin_ia32_vfmsubpd, __builtin_ia32_vfmsubps256 and. __builtin_ia32_vfmsubpd256. * config/i386/sse.md (fma4i_fmsub_): New. (_fmsub__maskz): Likewise. (*fma_fmsub__bcst_1): Likewise. (*fma_fmsub__bcst_2): Likewise. (*fma_fmsub__bcst_3): Likewise. (fmai_vmfmsub_): Likewise. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512f-fmsub-df-zmm-1.c: New test. * gcc.target/i386/avx512f-fmsub-sf-zmm-1.c: Likewise. * gcc.target/i386/avx512f-fmsub-sf-zmm-2.c: Likewise. * gcc.target/i386/avx512f-fmsub-sf-zmm-3.c: Likewise. * gcc.target/i386/avx512f-fmsub-sf-zmm-4.c: Likewise. * gcc.target/i386/avx512f-fmsub-sf-zmm-5.c: Likewise. * gcc.target/i386/avx512f-fmsub-sf-zmm-6.c: Likewise. * gcc.target/i386/avx512f-fmsub-sf-zmm-7.c: Likewise. * gcc.target/i386/avx512f-fmsub-sf-zmm-8.c: Likewise. * gcc.target/i386/avx512vl-fmsub-sf-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-fmsub-sf-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-df-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-7.c trunk/gcc/testsuite/gcc.target/i386/avx512f-fmsub-sf-zmm-8.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-fmsub-sf-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-fmsub-sf-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avx512vlintrin.h trunk/gcc/config/i386/fmaintrin.h trunk/gcc/config/i386/i386-builtin.def trunk/gcc/config/i386/sse.md
[Bug c++/50169] [DR 2141] "new struct X {{}};" incorrectly treated as an invalid struct-definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50169
--- Comment #8 from Nathan Ridge ---
(In reply to Eric Gallager from comment #7)
> (In reply to Nathan Ridge from comment #6)
> > Here is another test case that MSVC accepts but GCC rejects:
> >
> > struct A {};
> > struct A* b = (1 == 1) ? new struct A : new struct A;
>
> Is this really the same thing though?
I believe it's code that was made valid by DR2141, yes. I elaborate on my
reasoning in the corresponding clang bug:
https://bugs.llvm.org/show_bug.cgi?id=34993
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #17 from Harald van Dijk --- (In reply to Steinar H. Gunderson from comment #16) > Since you're asking (presumably rhethorically): I would certainly recommend > that this code be changed, yes, and I don't find the author's intent obvious > at all. I'm surprised by that. I'm not the one who wrote the code, but it seemed obvious to me when I started working with it. > The fix that comes to mind is to scope the case clause: Okay, that's cleaner than what I had suggested. Still, I hope you will check how much software uses this before deciding on whether to include the warning in -Wall. I can probably try a rebuild of my current system with that warning turned into an error to get an estimate of how big the impact will be, if you like, though it will not be as extensive as if one of the distros were willing to include it in their next mass rebuild.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #16 from Steinar H. Gunderson ---
Since you're asking (presumably rhethorically): I would certainly recommend
that this code be changed, yes, and I don't find the author's intent obvious at
all. The fix that comes to mind is to scope the case clause:
void f4(int a) {
switch (a) {
case 0: {
int i = f1();
f3(i);
break;
}
case 1: {
int i = f2();
f3(i);
break;
}
}
}
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #15 from Harald van Dijk --- (In reply to Segher Boessenkool from comment #10) > The initialisation (the call to f1) could have a side effect, but the > a==1 case skips that. GCC is right to warn here in my opinion. With an explicit -Wjump-misses-init, sure, that's the point of the warning. With -Wall, no, as there is nothing wrong with the code and it's quite intentional that the initialisation is skipped. Would you recommend to the author of whoever wrote that that the initialiser should be taken out of the declaration and put in an assignment on a separate line? That makes no sense to me. (And by the way, this is not hypothetical. This warning *does* trigger on code I work on.) The side effect is irrelevant, by the way, as the warning is triggered even if the initialiser is constant. And warnings that are likely to trigger on perfectly valid code that behaves exactly as the author intended shouldn't be included in -Wall, per your own comment.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #14 from Segher Boessenkool --- I am saying that no warning should warn for things that are valid C but invalid C++, except with -Wc++-compat; not for that reason, anyway. -Wjump-misses-init should warn here: the jump does miss the init! And it can be quite harmful in cases, and is trivial to work around. But warning for constructs that are not valid in C++, when compiling C code (and not asking for such a warning specifically) is a disservice to the user.
[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672
--- Comment #10 from Bernd Edlinger ---
untested patch:
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c (revision 265240)
+++ gcc/gimple-fold.c (working copy)
@@ -2715,6 +2715,7 @@ gimple_fold_builtin_stxcpy_chk (gimple_stmt_iterat
return false;
gimple_seq stmts = NULL;
+ len = force_gimple_operand (len, , true, NULL_TREE);
len = gimple_convert (, loc, size_type_node, len);
len = gimple_build (, loc, PLUS_EXPR, size_type_node, len,
build_int_cst (size_type_node, 1));
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c (revision 265240)
+++ gcc/tree-ssa-strlen.c (working copy)
@@ -2602,6 +2602,13 @@ handle_builtin_strcat (enum built_in_function bcod
len = force_gimple_operand_gsi (gsi, len, true, NULL_TREE, true,
GSI_SAME_STMT);
}
+ if (objsz)
+{
+ objsz = fold_build2_loc (loc, MINUS_EXPR, TREE_TYPE (objsz),
+ objsz, unshare_expr (dstlen));
+ objsz = force_gimple_operand_gsi (gsi, objsz, true, NULL_TREE, true,
+ GSI_SAME_STMT);
+}
if (endptr)
dst = fold_convert_loc (loc, TREE_TYPE (dst), unshare_expr (endptr));
else
[Bug fortran/87644] [7/8/9 Regression] ICE due to variable named "parameters"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- (In reply to Tobias Burnus from comment #3) > parameterA = 7 ! Variant C - ditto, but why no space required with free > form? I guess this is from the days when identifiers could only have six letters. There was no ambiguity for such a long variable name... This is one of the consequences of allowing too many legacy extensions, the have an impace on the main compiler :-(
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 --- Comment #10 from Paul Thomas --- Author: pault Date: Sun Oct 21 17:32:06 2018 New Revision: 265353 URL: https://gcc.gnu.org/viewcvs?rev=265353=gcc=rev Log: 2018-10-21 Paul Thomas PR fortran/71880 * trans-expr.c (gfc_trans_pointer_assignment): Set the string length for array valued deferred length lhs. 2018-10-21 Paul Thomas PR fortran/71880 * gfortran.dg/deferred_character_31.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_31.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #13 from Steinar H. Gunderson --- That could be (I disagree, but that's another debate), but the question was whether allowing this case would improve the warning or not. If you change it to allowing such a case, you also make -Wc++-compat less good at its job (unless you add yet another warning of course).
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #12 from Segher Boessenkool --- That is not a reason to have the warning in C, not without some "-Wc++-compat" or similar; and in C++ it should be an error you say, not a warning at all.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #11 from Steinar H. Gunderson --- It is also not legal (side effects or not) when compiling as C++, which is one of the reasons for having this warning.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #10 from Segher Boessenkool --- The initialisation (the call to f1) could have a side effect, but the a==1 case skips that. GCC is right to warn here in my opinion.
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 Yury Gribov changed: What|Removed |Added CC||ygribov at gcc dot gnu.org --- Comment #7 from Yury Gribov --- *** Bug 87677 has been marked as a duplicate of this bug. ***
[Bug bootstrap/87677] Isl bootstrap crash in extract_range_from_binary_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87677 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Yury Gribov --- . *** This bug has been marked as a duplicate of bug 87640 ***
[Bug bootstrap/87677] Isl bootstrap crash in extract_range_from_binary_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87677 --- Comment #3 from Yury Gribov --- (In reply to Aldy Hernandez from comment #1) > Is this fixed by the proposed patch to pr87640? If so, perhaps this is a > duplicate. Ah, sorry, it's indeed a dup. I thought you were talking about #87633
[Bug bootstrap/87677] Isl bootstrap crash in extract_range_from_binary_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87677 --- Comment #2 from Yury Gribov --- (In reply to Aldy Hernandez from comment #1) > Is this fixed by the proposed patch to pr87640? If so, perhaps this is a > duplicate. No, I think it's a separate issue. Combine_bounds call below fails to compute min_op0 which causes generation of wrong vrange: /* Build the bounds. */ combine_bound (code, wmin, min_ovf, expr_type, min_op0, min_op1);
[Bug other/39363] [meta-bug] pending patches from ARC International (UK) Ltd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39363 Bug 39363 depends on bug 39302, which changed state. Bug 39302 Summary: [meta-bug] bugs waiting for Copyright Assignment acknowledgemt for ARC International (UK) Ltd https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39302 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug other/39302] [meta-bug] bugs waiting for Copyright Assignment acknowledgemt for ARC International (UK) Ltd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39302 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jorn Wolfgang Rennecke --- (In reply to Eric Gallager from comment #2) > (In reply to Jorn Wolfgang Rennecke from comment #1) > > Confirmation received. I'll have to send out the patches now. > > Have you done this yet? Yes, see other/39363 and the various ARC branches from that time. > Also does this need to keep the "meta-bug" label Yes. This 'bug' describes and tracks state of a set of other bugs, it is not a GNU software bug in its own right. OTOH, the issue being tracked by this meta-bug - need for (verification of) Copyright assignment for patches from ARC International (UK) Ltd - has been resolved, and the dependent bugs are thus no longer blocked (since comment #1), so moving this to FIXED.
[Bug rtl-optimization/55531] peephole2 pattern with multiple insns with match_parallel insn causes corrupted peephole2_insns matching function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55531 --- Comment #2 from Jorn Wolfgang Rennecke --- (In reply to Eric Gallager from comment #1) > so this is... what, wrong-code? ice-on-valid-code? build? > > (I should go to bed instead of trying to figure this out...) ice-on-valid-code, and consequently a build issue.
[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672
--- Comment #9 from Bernd Edlinger ---
reduced test case:
$ cat pr87672.c
char buf[40];
void test (int x)
{
__builtin_strcpy(buf, "test");
__builtin___strcat_chk(buf, "postfix" + x, sizeof(buf));
}
$ gcc -O2 -S -Wall pr87672.c
pr87672.c: In function 'test':
pr87672.c:2:6: error: invalid operand in unary operation
2 | void test (int x)
| ^~~~
pr87672.c:2:6: error: incorrect sharing of tree nodes
(ssizetype) _1
_8 = (long unsigned int) ((ssizetype) _1 <= 7 ? 7 - (ssizetype) _1 : 0);
during GIMPLE pass: vrp
pr87672.c:2:6: internal compiler error: verify_gimple failed
0xd58395 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:5422
0xc3534f execute_function_todo
../../gcc-trunk/gcc/passes.c:1925
0xc3623e execute_todo
../../gcc-trunk/gcc/passes.c:1979
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug bootstrap/87677] Isl bootstrap crash in extract_range_from_binary_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87677 --- Comment #1 from Aldy Hernandez --- Is this fixed by the proposed patch to pr87640? If so, perhaps this is a duplicate.
[Bug middle-end/87670] [9 Regression] CPU2006 401.bzip2 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87670 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #1 from Aldy Hernandez --- Is this a duplicate of pr87640?
[Bug bootstrap/87677] New: Isl bootstrap crash in extract_range_from_binary_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87677 Bug ID: 87677 Summary: Isl bootstrap crash in extract_range_from_binary_expr_1 Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ygribov at gcc dot gnu.org Target Milestone: --- Created attachment 44875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44875=edit Repro Trunk ICEs when trying to bootstrap with ISL 0.18 (downloaded by running contrib/download_prerequisites): $ /home/yugr/src/gcc/configure --disable-multilib --enable-checking --target=x86_64-linux-gnu --host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-languages=c,c++ && make -j4 ... /home/yugr/src/gcc/isl/isl_tab_pip.c: In function ‘isl_tab_basic_set_non_trivial_lexmin’: /home/yugr/src/gcc/isl/isl_tab_pip.c:5087:21: internal compiler error: in check, at tree-vrp.c:155 5087 | __isl_give isl_vec *isl_tab_basic_set_non_trivial_lexmin( I attached preprocessed code (compile with -O2).
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #9 from Harald van Dijk ---
(In reply to Segher Boessenkool from comment #8)
> -Wall please, unless there are frequent false positives.
-Wjump-misses-init warns for harmless code such as
int f1();
int f2();
void f3(int);
void f4(int a) {
switch (a) {
case 0:;
int i = f1();
f3(i);
break;
case 1:
i = f2();
f3(i);
break;
}
}
Here, yes, the initialisation is jumped over, but the variable is never used
uninitialised. clang manages to avoid warning for this.
[Bug c++/87676] New: Presence of variadic constructor template breaks overload resolution for other constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87676
Bug ID: 87676
Summary: Presence of variadic constructor template breaks
overload resolution for other constructors
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
Reduced testcase:
struct S1 { S1(int, int, int); };
struct S2 {
S2(const S2 &) = delete;
S2(const S1 &);
S2(S1 &&);
template S2(T &&...);
};
S2 s({1, 2, 3});
I expect this to compile using the S2(S1 &&) constructor. Instead, GCC emits an
error:
test.cc:8:15: error: call of overloaded ‘S2()’ is ambiguous
S2 s({1, 2, 3});
^
test.cc:5:3: note: candidate: ‘S2::S2(S1&&)’
S2(S1 &&);
^~
test.cc:4:3: note: candidate: ‘S2::S2(const S1&)’
S2(const S1 &);
^~
test.cc:3:3: note: candidate: ‘S2::S2(const S2&)’
S2(const S2 &) = delete;
^~
That is, ambiguous between the three non-template constructors. But if the
constructor template is commented out, GCC no longer sees it as ambiguous, GCC
does prefer the S2(S1 &&) overload.
I do not understand why the presence of a constructor template would affect the
overload resolution between the other constructors. FWIW, clang behaves the
same way as GCC, which is a sign that there might be a good reason for the
current behaviour, but MSVC and Intel do accept the code.
[Bug demangler/87675] New: Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 Bug ID: 87675 Summary: Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: N1705695H at e dot ntu.edu.sg Target Milestone: --- Created attachment 44874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44874=edit POC An issue was discovered in cp-demangle.c in GNU libiberty, as distributed in GNU Binutils 2.31. Stack Exhaustion occurs in the C++ demangling functions provided by libiberty, and there is a stack consumption problem caused by recursive stack frames: next_is_type_qua() and cplus_demangle_type() Please use the "./nm -C $POC" to reproduce the bug. This result can trigger different Stack Overflow, you can try several times. To reproduce this bug. You need to build bintuils-2.31 with ASAN. Here is the compile Option. Another approach is to set the break Point and debug it, as the stack overflow didn't crash the program. > CC=clang LDFLAGS="-ldl" CFLAGS="-DFORTIFY_SOURCE=2 -fstack-protector-all > -fsanitize=undefined,address -fno-omit-frame-pointer -g -O0 -Wno-error" > ./configure --disable-shared --disable-gdb --disable-libdecnumber > --disable-sim The ASAN dumps the stack trace as follows: > ASAN:DEADLYSIGNAL > = > ==9864==ERROR: AddressSanitizer: stack-overflow on address 0x7fff9e5c9f58 (pc > > 0x009684ac bp 0x sp 0x7fff9e5c9f58 T0) > #0 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #1 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #2 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #3 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #4 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #5 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #6 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #7 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #8 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #9 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #10 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #11 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #12 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #13 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #14 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #15 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #16 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #17 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #18 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #19 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > #20 0x9684ab in next_is_type_qual cp-demangle.c:2290 > #21 0x9684ab in cplus_demangle_type cp-demangle.c:2387 > ... > # 0xc580c22 () > SUMMARY: AddressSanitizer: stack-overflow cp-demangle.c:2290 in > next_is_type_qual > ==9864==ABORTING > AAborted
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 --- Comment #13 from coypu --- I sent this to gcc-patches for netbsd/eabi and stop picking arm6 -mcpu for oabi too: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01256.html for all of arm to stop defaulting to non-existent -mcpu=arm6: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01262.html
[Bug target/87674] New: AVX512: incorrect intrinsic signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87674
Bug ID: 87674
Summary: AVX512: incorrect intrinsic signature
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
Hi,
I'm seeing a number of warnings related to the following three intrinsics,
which appaer to have an incorrect signature. The fix is easy: simply change
__mmask16 to __mmask8 for those definitions (and this is also what's correct
according to Intel's Intrinsics Explorer)
/home/wjakob/dist/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/avx512vlintrin.h:
In function ‘__m128i _mm_mask_mullo_epi32(__m128i, __mmask16, __m128i,
__m128i)’:
/home/wjakob/dist/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/avx512vlintrin.h:9055:23:
warning: conversion from ‘__mmask16’ {aka ‘short unsigned int’} to ‘unsigned
char’ may change value [-Wconversion]
(__v4si) __W, __M); ^~~
/home/wjakob/dist/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/avx512vlbwintrin.h:
In function ‘__m128i _mm_mask_packus_epi32(__m128i, __mmask16, __m128i,
__m128i)’:
/home/wjakob/dist/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/avx512vlbwintrin.h:4354:25:
warning: conversion from ‘__mmask16’ {aka ‘short unsigned int’} to ‘unsigned
char’ may change value [-Wconversion]
(__v8hi) __W, __M); ^~~
/home/wjakob/dist/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/avx512vlbwintrin.h:
In function ‘__m128i _mm_mask_packs_epi32(__m128i, __mmask16, __m128i,
__m128i)’:
/home/wjakob/dist/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/avx512vlbwintrin.h:4397:25:
warning: conversion from ‘__mmask16’ {aka ‘short unsigned int’} to ‘unsigned
char’ may change value [-Wconversion]
(__v8hi) __W, __M); ^~~
Best,
Wenzel
[Bug target/72784] AVX512: Assembler failure when compiling on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72784 Wenzel Jakob changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Wenzel Jakob --- Closing this due to lack of attention/relevance.
[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-21 Known to work||8.0 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #8 from Bernd Edlinger --- thus confirmed.
[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672 --- Comment #7 from Bernd Edlinger --- Until dom3, everything is OK... i386.ii.176t.dom3: [local count: 267871744]: __builtin___strcat_chk (, _14, 40); output_asm_insn (, operands_23(D)); goto ; [100.00%] ... but strlen does an invalid transformation, which is does not even cause the ICE, the last parameter should be 36, because the strcpy_chk needs the size of the remaining buffer after the first 4 bytes... i386.ii.177t.strlen: [local count: 267871744]: _27 = + 4; __builtin___strcpy_chk (_27, _14, 40); output_asm_insn (, operands_23(D)); goto ; [100.00%] i386.ii.178t.thread4: [local count: 267871744]: _27 = + 4; __builtin___strcpy_chk (_27, _14, 40); output_asm_insn (, operands_23(D)); goto ; [100.00%] ... and now in vrp2, the strcpy_chk is replaced by something that looks not gimplified, which causes the ICE: i386.ii.179t.vrp2: [local count: 267871744]: _58 = (long unsigned int) ((ssizetype) _17 <= 7 ? 7 - (ssizetype) _17 : 0); _59 = _58 + 1; __builtin___memcpy_chk ([(void *) + 4B], _14, _59, 40); output_asm_insn (, operands_23(D)); goto ; [100.00%]
[Bug fortran/87673] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #1 from Paul Thomas --- I Have just noticed that the problem goes away for 6-branch through trunk is the order of the contained procedures is changed. This points a finger at parse.c/primary.c or the resolution of contained functions. Paul
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Oct 21 10:35:36 2018 New Revision: 265351 URL: https://gcc.gnu.org/viewcvs?rev=265351=gcc=rev Log: i386: Enable AVX512 memory broadcast for FP mul Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for FP mul operations. gcc/ PR target/72782 * config/i386/sse.md (*mul3_bcst): New. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512f-mul-df-zmm-1.c: New test. * gcc.target/i386/avx512f-mul-sf-zmm-1.c: Likewise. * gcc.target/i386/avx512f-mul-sf-zmm-2.c: Likewise. * gcc.target/i386/avx512f-mul-sf-zmm-3.c: Likewise. * gcc.target/i386/avx512f-mul-sf-zmm-4.c: Likewise. * gcc.target/i386/avx512f-mul-sf-zmm-5.c: Likewise. * gcc.target/i386/avx512f-mul-sf-zmm-6.c: Likewise. * gcc.target/i386/avx512vl-mul-sf-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-mul-sf-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-mul-df-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mul-sf-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mul-sf-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mul-sf-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mul-sf-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mul-sf-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mul-sf-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-mul-sf-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-mul-sf-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/87673] New: Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 Bug ID: 87673 Summary: Errors caused by using function for character length in allocate with typespec Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 44873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44873=edit Reduced source for the problem The attached causes a variety of failures, ranging from a segfault in resolve.c to the following message: [pault@pc30 pr85603]$ ~/irun/bin/gfortran -static-libgfortran -fdump-tree-original ~/prs/pr85603/f*.f90 -g /home/pault/prs/pr85603/fragment.f90:46:24: 46 | ALLOCATE( CHARACTER(get_char_result_length(len(string%chars), length)) :: & |1 Error: Reference to impure function ‘_chars_length’ at (1) within a PURE procedure /home/pault/prs/pr85603/fragment.f90:75:10: 75 | end module | 1 Warning: _chars_length at (1) is not a procedure If the assignment to 'klen' is included, the function identified changes to '__vtab_v_Varying_string'. Using 'klen' in the typespec, instead of the function call works fine. I have to drop the search for the source of the problem right now and so I am posting it. Paul
[Bug fortran/86527] gfortran console I/O not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86527 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dominique d'Humieres --- No feedback, closing as INVALID.
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Dominique d'Humieres changed: What|Removed |Added CC||mrestelli at gmail dot com --- Comment #11 from Dominique d'Humieres --- *** Bug 77643 has been marked as a duplicate of this bug. ***
[Bug fortran/77643] ICE with "character(len=:), pointer :: p => null()"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77643 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dominique d'Humieres --- > It looks like a duplicate of pr70149. It is fixed at revision r265266. No objection, then marked as duplicate. *** This bug has been marked as a duplicate of bug 70149 ***
[Bug target/87662] Missing AVX512VL intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87662 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Oct 21 10:23:58 2018 New Revision: 265350 URL: https://gcc.gnu.org/viewcvs?rev=265350=gcc=rev Log: i386: Add missing AVX512VL or/xor intrinsics gcc/ PR target/87662 * i386/avx512vlintrin.h (_mm256_or_epi32): New. (_mm_or_epi32): Likewise. (_mm256_xor_epi32): Likewise. (_mm_xor_epi32): Likewise. (_mm256_or_epi64): Likewise. (_mm_or_epi64): Likewise. (_mm256_xor_epi64): Likewise. (_mm_xor_epi64): Likewise. gcc/testsuite/ PR target/87662 * gcc.target/i386/pr87662.c Added: trunk/gcc/testsuite/gcc.target/i386/pr87662.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512vlintrin.h trunk/gcc/testsuite/ChangeLog
[Bug c++/87668] [OpenMP] Complains about loop bound variable not being shared, even though unused in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87668 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- GCC is correct here. Even with the recent 5.0 clarifications, those expressions are to be evaluated before the worksharing-loop construct, but still inside of the parallel region, so with default(none) d needs to be specified on the parallel (e.g. shared or firstprivate).
[Bug middle-end/86336] [9 regression] ICE in omp-low.c:7879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86336 --- Comment #4 from Jakub Jelinek --- So fixed?
[Bug bootstrap/87672] [9 regression] 81512c36 causes ICE in bootstrap stage 3 using "-D_FORTIFY_SOURCE=2" (invalid operand in unary operation, incorrect sharing of tree nodes, verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672 --- Comment #6 from jamespharvey20 at gmail dot com --- P.S. In case it sheds any light, I just found out that after the build failure, if I manually re-run the stage 3 "./prev-gcc/xg++ ... .../i386/i386.c" command without "-D_FORTIFY_SOURCE=2", it doesn't error. (I was curious if the stage 2 gcc was broken from being compiled with the option, and would fail on this file no matter what.)
[Bug fortran/87337] Internal compiler error on coarrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87337 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-10-21 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Seems to at least compile properly with GCC 9, FWIW. It compiles also with 7.3 and 8.2. At run time I get At line 341 of file pr87337.f90 Fortran runtime error: Attempt to DEALLOCATE unallocated 'f' if the code is complied with -fcoarray=lib -lcaf_single. If I add -fcheck=all, I get At line 341 of file pr87337.f90 Fortran runtime error: Index '127' of dimension 1 of array 'f' above upper bound of 126
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2018-10-21 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #6 from Dominique d'Humieres --- > Martin: Can we close this as INVALID or WORKSFORME? > > Or is there still an issue? - At least it seems to work for -m32 and > -m64 is not supported by construction of the x86_64 ABI. May be this should be better documented in section '7.2.1 ATTRIBUTES directive' of the Fortran manual.
[Bug fortran/87568] Gfortran compile fails with bogus error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87568 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (9.0).
[Bug fortran/87669] Select type, incorrect handling of parameterized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87669 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-21 Blocks||82173 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87633 --- Comment #8 from Yury Gribov --- Posted patch in https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01266.html
[Bug c/87387] trunk/gcc/builtins.c:585:7: warning: -Wself-assign problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87387 --- Comment #6 from jamespharvey20 at gmail dot com --- This fix introduces bug 87672.
