[Bug target/96174] New: AVX-512 functions missing when compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
Bug ID: 96174
Summary: AVX-512 functions missing when compiled without
optimization
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
The avx512fintrin.h header sometimes uses different implementations depending
on whether __OPTIMIZE__ is defined, but many functions are missing if
__OPTIMIZE__ is not defined.
Here is a trivial test case:
#include
__mmask16 foo(__m512 a, __m512 b) {
return _mm512_cmplt_ps_mask(a, b);
}
On Compiler Explorer: https://godbolt.org/z/83jP63
I ran into this with _mm512_cmplt_ps_mask, but it looks like this all the
_mm512_cmp*_{pd,ps}_mask functions have the same problem.
[Bug middle-end/96136] [11 regression] ICE in reduce_to_bit_field_precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96136 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Christophe Lyon --- This was fixed by the fix for PR96151, thanks.
[Bug fortran/95998] gfc_typename use of static memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998
--- Comment #3 from Dominique d'Humieres ---
> If we ever have three occurences of gfc_typename in a function list,
> like
>
> foo (gfc_typename(a), gfc_typename(b), gfc_typename(c));
>
> we will get the wrong result for the third one. We will also get
> a wrong result for
>
> pa = gfc_typename(a);
> pb = gfc_typename(b);
> pc = gfc_typename(c);
>
> because then pa will point to the same memory as pc.
OK. I think I am now starting to understand how this proc works.
I have looked at the occurrences of gfc_typename, and AFAICT they appear only
once or twice within
the same gfc_error, except for (line 2303 in check.c)
gfc_error ("The function passed as OPERATOR at %L has arguments of type "
"%s and %s but shall have type %s", &op->where,
gfc_typename (&formal->sym->ts),
gfc_typename (&formal->next->sym->ts), gfc_typename (a));
but 'a' is a gfc_expr, while 'formal->sym->ts', and 'formal->next->sym->ts' are
gfc_typespec, so different procs and it should be OK.
Note that presently gfc_typename is only called in error messages and potential
problems will
only show as strange errors.
However in noticed a potential buffer overflow with DEC extensions:
static char buffer1[GFC_MAX_SYMBOL_LEN + 7]; /* 7 for "TYPE()" + '\0'. */
static char buffer2[GFC_MAX_SYMBOL_LEN + 7];
should be
static char buffer1[GFC_MAX_SYMBOL_LEN + 8]; /* 8 for "UNION()" + '\0'. */
static char buffer2[GFC_MAX_SYMBOL_LEN + 8];
[Bug c++/96141] ICE in gimplify: Coroutine and noexcept(false) destructor cause: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96141
--- Comment #3 from Bernd Baumanns ---
Is there something missing in that if? What must be changed?
This is assert fails:
/* ??? If this is a local variable, and it has not been seen in any
outer BIND_EXPR, then it's probably the result of a duplicate
declaration, for which we've already issued an error. It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
in g++.old-deja/g++.jason/binding.C. */
if (VAR_P (decl)
&& !DECL_SEEN_IN_BIND_EXPR_P (decl)
&& !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
&& decl_function_context (decl) == current_function_decl)
{
gcc_assert (seen_error ());
return GS_ERROR;
}
[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 Thomas Koenig changed: What|Removed |Added Keywords|needs-bisection |patch --- Comment #15 from Thomas Koenig --- Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549860.html .
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #35 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:267891bd3c7ce3e16662eb2be7273f0bc8be9e7e commit r11-2041-g267891bd3c7ce3e16662eb2be7273f0bc8be9e7e Author: H.J. Lu Date: Fri Jul 10 14:50:03 2020 -0700 x86: Require Linux target for PR target/93492 tests Since -fpatchable-function-entry is only supported on Linux and used by Linux kernel, require Linux target for PR target/93492 tests. PR target/93492 * gcc.target/i386/pr93492-1.c: Require Linux target. * gcc.target/i386/pr93492-2.c: Likewise. * gcc.target/i386/pr93492-3.c: Likewise. * gcc.target/i386/pr93492-4.c: Likewise. * gcc.target/i386/pr93492-5.c: Likewise.
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #36 from H.J. Lu --- Fixed for GCC 11.
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 93492, which changed state. Bug 93492 Summary: Broken code with -fpatchable-function-entry and -fcf-protection=full https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/93678] [9/10/11 Regression] ICE in 9.2/9.2.1 not happening in previous gfortran versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 Thomas Koenig changed: What|Removed |Added Summary|ICE in 9.2/9.2.1 not|[9/10/11 Regression] ICE in |happening in previous |9.2/9.2.1 not happening in |gfortran versions |previous gfortran versions Target Milestone|--- |9.4 CC||tkoenig at gcc dot gnu.org
[Bug fortran/93678] [9/10/11 Regression] ICE in 9.2/9.2.1 not happening in previous gfortran versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #5 from Thomas Koenig --- A somewhat smaller test case, which of course does nothing useful, but still reproduces the ICE: module mo_a implicit none type t_b integer :: n = 0 integer :: nr = 0 character, pointer :: buffer(:) => NULL() contains procedure :: unpackbytes => b_unpackbytes end type t_b character :: characterarraymold(1) contains subroutine b_unpackint(me, val) class(t_b), intent(inout) :: me integer, intent(out) :: val val = transfer(me%unpackbytes(transfer(val, characterarraymold)), val) end subroutine b_unpackint function b_unpackbytes(me, bytearraymold) result(res) class(t_b), intent(inout) :: me character, intent(in) :: bytearraymold(:) character, pointer :: res(:) end function b_unpackbytes end module mo_a
[Bug libstdc++/89417] helgrind detects a lock order violation inside std::scoped_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417 Federico Kircheis changed: What|Removed |Added Version|8.2.0 |10.1.0 --- Comment #1 from Federico Kircheis --- I've tested with g++10 (g++-10 (Debian 10.1.0-4) 10.1.0), and the situation is unchanged. Does anything speak against adding the proposed "make_lock" logic inside std::lock_guard? Are there any drawbacks?
[Bug fortran/93678] [9/10/11 Regression] ICE with TRANSFER and typebound procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 Thomas Koenig changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10/11 Regression] ICE |9.2/9.2.1 not happening in |with TRANSFER and typebound |previous gfortran versions |procedures --- Comment #6 from Thomas Koenig --- So, it is the typebound procedure that causes the problem. This does not ICE: val = transfer(b_unpackbytes(me, characterarraymold), val) But this does ICE: val = transfer(me%unpackbytes(characterarraymold), val)
[Bug fortran/93948] Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-07-12 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #5 from Dominique d'Humieres --- >From the Steve's comments, could this PR closed as WONTFIX?
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-07-12 Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1
[Bug c++/96170] Enhancement: allow requires-clause checking of statement expression substitution success or failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96170 --- Comment #1 from Will Wray --- Opened an equivalent enhancement request for Clang https://bugs.llvm.org/show_bug.cgi?id=46691
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-07-12 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug libfortran/93567] G edit descriptor uses E instead of F editing in rounding mode UP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93567 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-07-12 --- Comment #2 from Dominique d'Humieres --- See also pr93592.
[Bug fortran/93736] Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-07-12 Status|UNCONFIRMED |NEW
[Bug middle-end/96175] New: Failure to optimize memory stores of double literals properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96175
Bug ID: 96175
Summary: Failure to optimize memory stores of double literals
properly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f(double *x)
{
*x = 1.0;
}
With -O3, LLVM generates this :
f(double*): # @f(double*)
movabs rax, 4607182418800017408
mov qword ptr [rdi], rax
ret
GCC generates this :
f(double*):
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rdi], rax
ret
.LC0:
.long 0
.long 1072693248
This also occurs on every other architecture I tested (arm and powerpc64le,
though only with GCC 9). GCC is weirdly insistent on having a literal stored in
const data instead of just having it in the code, which seems inefficient.
[Bug target/96175] Failure to optimize memory stores of double literals properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96175 Andrew Pinski changed: What|Removed |Added Component|middle-end |target --- Comment #1 from Andrew Pinski --- Each target decides how liberals are handled. So this is a target issue. Iirc aarch64 was fixed in gcc 10 for an example.
[Bug target/96174] AVX-512 functions missing when compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-07-12 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 48865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48865&action=edit gcc11-pr96174.patch Untested fix.
[Bug target/96176] New: Failure to omit extraneous movzx in atomic compare exchange with unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96176
Bug ID: 96176
Summary: Failure to omit extraneous movzx in atomic compare
exchange with unsigned char
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f(unsigned char *addr, unsigned char old_val, unsigned char new_val)
{
__atomic_compare_exchange_n(addr, &old_val, new_val, 0, 0, 0);
}
On x86 with -O3, LLVM generates this :
f(unsigned char*, unsigned char, unsigned char): # @f(unsigned char*, unsigned
char, unsigned char)
mov eax, esi
lock cmpxchg byte ptr [rdi], dl
ret
GCC generates this :
f(unsigned char*, unsigned char, unsigned char):
mov eax, esi
movzx edx, dl
lock cmpxchg BYTE PTR [rdi], dl
ret
[Bug target/96177] New: ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96177
Bug ID: 96177
Summary: ICE: in extract_insn, at recog.c:2294 (error:
unrecognizable insn)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-11.0.0-alpha20200705 snapshot (g:cc9a9229285a26ac12bc8de53237ce9c4d42f867)
ICEs when compiling the following testcase, extracted from
gcc/testsuite/gcc.target/powerpc/xxgenpc-runnable.c, w/ -mcpu=power10:
__attribute__ ((altivec (vector__))) char
ew (__attribute__ ((altivec (vector__))) char uk)
{
return __builtin_vec_xxgenpcvm (uk, 1);
}
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mcpu=power10 -c rwmfukd0.c
rwmfukd0.c: In function 'ew':
rwmfukd0.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 7 6 10 2 (set (reg:V16QI 117 [ _2 ])
(unspec:V16QI [
(reg:V16QI 119)
(const_int 1 [0x1])
] UNSPEC_XXGENPCV)) "rwmfukd0.c":4:10 -1
(nil))
during RTL pass: vregs
rwmfukd0.c:5:1: internal compiler error: in extract_insn, at recog.c:2294
0x696456 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/rtl-error.c:108
0x696476 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/rtl-error.c:116
0x694697 extract_insn(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/recog.c:2294
0xb23a93 instantiate_virtual_regs_in_insn
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/function.c:1607
0xb23a93 instantiate_virtual_regs
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/function.c:1977
0xb23a93 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200705/work/gcc-11-20200705/gcc/function.c:2026
[Bug target/96178] New: ICE in emit_move_multi_word, at expr.c:3721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96178
Bug ID: 96178
Summary: ICE in emit_move_multi_word, at expr.c:3721
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200712 snapshot (g:267891bd3c7ce3e16662eb2be7273f0bc8be9e7e)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/powerpc/mma-builtin-2.c, w/ -mvsx:
void
foo2 (void)
{
__vector_quad acc;
__vector_pair vecp0;
__attribute__ ((__vector_size__ (16))) unsigned char vec1;
__builtin_mma_pmxvf64ger (&acc, vecp0, vec1, 5, 3);
}
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mvsx -c vtmf2pkq.c
vtmf2pkq.c: In function 'foo2':
vtmf2pkq.c:8:3: error: '__builtin_mma_pmxvf64ger' requires the '-mmma' option
8 | __builtin_mma_pmxvf64ger (&acc, vecp0, vec1, 5, 3);
| ^~
during RTL pass: expand
vtmf2pkq.c:8:3: internal compiler error: in emit_move_multi_word, at
expr.c:3721
0x60261b emit_move_multi_word
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/expr.c:3721
0xabfc4e emit_move_insn(rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/expr.c:3929
0x983de9 load_register_parameters
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/calls.c:3084
0x983de9 expand_call(tree_node*, rtx_def*, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/calls.c:4530
0x129306f rs6000_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/config/rs6000/rs6000-call.c:12276
0x971094 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/builtins.c:7894
0xabce4e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/expr.c:11232
0x999b98 expand_expr
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/expr.h:282
0x999b98 expand_call_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/cfgexpand.c:2703
0x999b98 expand_gimple_stmt_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/cfgexpand.c:3682
0x999b98 expand_gimple_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/cfgexpand.c:3847
0x99f614 expand_gimple_basic_block
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/cfgexpand.c:5888
0x9a1387 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200712/work/gcc-11-20200712/gcc/cfgexpand.c:6572
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #38 from jojo --- (In reply to Martin Liška from comment #36) > (In reply to jojo from comment #35) > > (In reply to Martin Liška from comment #30) > > > A possible solution can be usage of '-flinker-output=nolto-rel -r' for > > > huge > > > files. > > > > it's useful for splitting huge files ? > > There's experiment I did: > > $ time g++ -O2 /tmp/gimple-match.ii -c > > real0m35.790s > user0m35.490s > sys0m0.268s > > $ time g++ -O2 /tmp/gimple-match.ii -c -flto > > real0m8.138s > user0m7.915s > sys0m0.202s > > $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o > gimple-match2.o > > real0m9.087s > user1m56.028s > sys0m3.292s > > $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o > gimple-match2.o --param lto-partitions=8 > > real0m7.350s > user0m48.548s > sys0m0.976s > > $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o > gimple-match2.o --param lto-partitions=4 > > real0m9.847s > user0m30.462s > sys0m0.392s > > so for N==4 we get to 8+10s = 18s (compared to the original 36s). And total > user time is 30+8, which is comparable > to the original 36s. It's looks a little cost down for huge file as insn-emit.c.. I want to use shell tool like 'csplit' to split it and compile parallelly
[Bug middle-end/94600] Ignored volatile specifier on loop unrolling and bitfield misoptimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600 --- Comment #9 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:a4aca1edaf37d43b2b7e9111825837a7a317b1b0 commit r11-2045-ga4aca1edaf37d43b2b7e9111825837a7a317b1b0 Author: Hans-Peter Nilsson Date: Sun Jul 5 20:50:52 2020 +0200 PR94600: fix volatile access to the whole of a compound object. The store to the whole of each volatile object was picked apart like there had been an individual assignment to each of the fields. Reads were added as part of that; see PR for details. The reads from volatile memory were a clear bug; individual stores questionable. A separate patch clarifies the docs. gcc: 2020-07-09 Richard Biener PR middle-end/94600 * expr.c (expand_constructor): Make a temporary also if we're storing to volatile memory. gcc/testsuite: 2020-07-09 Hans-Peter Nilsson PR middle-end/94600 * gcc.dg/pr94600-1.c, gcc.dg/pr94600-2.c, gcc.dg/pr94600-3.c, gcc.dg/pr94600-4.c, gcc.dg/pr94600-5.c, gcc.dg/pr94600-6.c, gcc.dg/pr94600-7.c, gcc.dg/pr94600-8.c: New tests.
[Bug middle-end/94600] Ignored volatile specifier on loop unrolling and bitfield misoptimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:6f49c66ed4e060c333d8bcd5e4ae127ab7bca15b commit r10-8468-g6f49c66ed4e060c333d8bcd5e4ae127ab7bca15b Author: Hans-Peter Nilsson Date: Sun Jul 5 20:50:52 2020 +0200 PR94600: fix volatile access to the whole of a compound object. The store to the whole of each volatile object was picked apart like there had been an individual assignment to each of the fields. Reads were added as part of that; see PR for details. The reads from volatile memory were a clear bug; individual stores questionable. A separate patch clarifies the docs. gcc: 2020-07-09 Richard Biener PR middle-end/94600 * expr.c (expand_constructor): Make a temporary also if we're storing to volatile memory. gcc/testsuite: 2020-07-09 Hans-Peter Nilsson PR middle-end/94600 * gcc.dg/pr94600-1.c, gcc.dg/pr94600-2.c, gcc.dg/pr94600-3.c, gcc.dg/pr94600-4.c, gcc.dg/pr94600-5.c, gcc.dg/pr94600-6.c, gcc.dg/pr94600-7.c, gcc.dg/pr94600-8.c: New tests. (cherry picked from commit a4aca1edaf37d43b2b7e9111825837a7a317b1b0)
