[Bug analyzer/102225] New: [12 Regression] ICE in get_or_create_int_cst, at analyzer/region-model-manager.cc:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102225
Bug ID: 102225
Summary: [12 Regression] ICE in get_or_create_int_cst, at
analyzer/region-model-manager.cc:227
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-12.0.0-alpha20210905 snapshot (g:a827909537cf085e5673ca7816b7bd7151d89fc5)
ICEs when compiling the following testcase, reduced from
test/clang-tidy/checkers/bugprone-misplaced-pointer-arithmetic-in-alloc.c from
the clang-tools-extra 12.0.0 testsuite, w/ -O1 -fchecking:
void bad_realloc(char *s, int n) {
char *p = __builtin_realloc(s, n);
}
% gcc-12.0.0 -O1 -fanalyzer -c cyjxpbay.c
during IPA pass: analyzer
cyjxpbay.c: In function 'bad_realloc':
cyjxpbay.c:2:13: internal compiler error: in get_or_create_int_cst, at
analyzer/region-model-manager.cc:227
2 | char *p = __builtin_realloc(s, n);
| ^~~
0x78915e ana::region_model_manager::get_or_create_int_cst(tree_node*,
poly_int<1u, long>)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/analyzer/region-model-manager.cc:227
0x78926e ana::region_model_manager::get_or_create_int_cst(tree_node*,
poly_int<1u, long>)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/tree.h:3532
0x12590f5 update_model
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/analyzer/region-model-impl-calls.cc:544
0x1228c17 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/analyzer/engine.cc:3455
0x122979a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/analyzer/engine.cc:2787
0x122bc65 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/analyzer/engine.cc:5363
0x122ca5c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/analyzer/engine.cc:5434
0x121c868 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/analyzer/analyzer-pass.cc:87
[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #7 from Gabriel Ravier --- Also, `-ffast-math` seems to "fix" this, since in that case the code is recognized as an ABS_EXPR pattern and as such results in the same code being emitted without the xor. Is there any reason this isn't the case without fast math ? I'd assume the xor wouldn't do anything w.r.t. conformance, personally.
[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 Gabriel Ravier changed: What|Removed |Added Summary|[12 regession] wrong code |[9/10/11/12 regession] |for `x * copysign(1.0, x)` |wrong code for `x * ||copysign(1.0, x)` --- Comment #6 from Gabriel Ravier --- Actually, I've only gotten a snapshot from the 5th, which does not appear to include HJ's patch from the 4th (which seems rather odd). Does it happen to fix this ? I'd assume it does not, since that patch just seems to care about not destructing the source and not about the emission of the xor that breaks this, but I can't know for sure rn.
[Bug target/102224] [12 regession] wrong code for `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #5 from Gabriel Ravier --- Actually it seems to me like this is a GCC 9 regression, ever since this pattern exists: GCC 9, 10 and 11 emit the exact same faulty code.
[Bug target/102224] [12 regession] wrong code for `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #4 from Andrew Pinski --- There was just a recent patch which touched this in the x86 backend.
[Bug target/102224] Incorrect compile on `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Component|tree-optimization |target Keywords||wrong-code
[Bug tree-optimization/102224] Incorrect compile on `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #3 from Gabriel Ravier --- Also seems like this might be unique to x86 as this compiles fine on Aarch64 (though while it doesn't try to do anything stupid like xoring the result with itself, it does still not optimize the XOR_SIGN to an ABS_EXPR at the GIMPLE level).
[Bug tree-optimization/102224] Incorrect compile on `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #2 from Gabriel Ravier --- (PS: by "x and y" I mean "the two arguments". If they're the same, GCC should obviously just optimize this to an abs as that's what it ends up being)
[Bug tree-optimization/102224] Incorrect compile on `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #1 from Gabriel Ravier --- (Note: this is a miscompile because it compiles as equivalent to `return 0;` as that's what `xorps xmm0, xmm0` will do)
[Bug tree-optimization/102224] New: Incorrect compile on `x * copysign(1.0, x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
Bug ID: 102224
Summary: Incorrect compile on `x * copysign(1.0, x)`
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
float f(float x, float y)
{
return x * copysignf(1.0f, x);
}
On latest trunk with -O3 on x86, this compiles to:
f(float):
andps xmm0, XMMWORD PTR .LC0[rip]
xorps xmm0, xmm0
ret
.LC0:
.long -2147483648
.long 0
.long 0
.long 0
This is likely because the XOR_SIGN pattern emitted by
convert_expand_mult_copysign fails to check that x and y are not the same
(note: it can be optimized to ABS_EXPR in that case).
[Bug tree-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178 --- Comment #2 from luoxhu at gcc dot gnu.org --- Verified 470.lbm doesn't show regression on Power8 with Ofast. runtime is 141 sec for r12-897, without that patch it is 142 sec.
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 --- Comment #3 from luoxhu at gcc dot gnu.org --- phiopt4 and sink2 are doing reverse optimizations: pr102008.c.200t.phiopt4: Hoisting adjacent loads from 3 and 4 into 2: _6 = foo_4(D)->a; _5 = foo_4(D)->b; pr102008.c.202t.sink2: Sinking _5 = foo_4(D)->b; from bb 2 to bb 4 Sinking _6 = foo_4(D)->a; from bb 2 to bb 3
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 --- Comment #2 from luoxhu at gcc dot gnu.org --- Confirmed if move the sink2 pass before phiopt4 could restore the previous instructons for this case: test: .LFB0: .cfi_startproc cmp w0, 1 ldp w0, w1, [x1] cselw0, w1, w0, ne ret .cfi_endproc diff --git a/gcc/passes.def b/gcc/passes.def index 945d2bc797c..83b8310f1ee 100644 --- a/gcc/passes.def +++ b/gcc/passes.def @@ -345,10 +345,10 @@ along with GCC; see the file COPYING3. If not see /* After late CD DCE we rewrite no longer addressed locals into SSA form if possible. */ NEXT_PASS (pass_forwprop); + NEXT_PASS (pass_sink_code); NEXT_PASS (pass_phiopt, false /* early_p */); NEXT_PASS (pass_fold_builtins); NEXT_PASS (pass_optimize_widening_mul); - NEXT_PASS (pass_sink_code); NEXT_PASS (pass_store_merging); NEXT_PASS (pass_tail_calls); ls *sink* pr102008.c.139t.sink1 pr102008.c.199t.sink2 ls *phiopt* pr102008.c.042t.phiopt1 pr102008.c.119t.phiopt2 pr102008.c.131t.phiopt3 pr102008.c.200t.phiopt4
[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 Andrew Pinski changed: What|Removed |Added Keywords||TREE --- Comment #4 from Andrew Pinski --- So how 4.4.x got the right answer at the tree level was just by accident really. VRP used SCEV which basically does a combine. Forwprop never happened of PointerPlus until 4.6. 4.5 removed the SCEV usage in VRP and removed the optimization ...
[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216
Andrew Pinski changed:
What|Removed |Added
Summary|False positive |[12 Regression] missed
|warray-bounds with -O2 |optimization causing
||Warray-bounds
Target Milestone|--- |12.0
Known to work||4.4.7
--- Comment #3 from Andrew Pinski ---
Here is a short testcase:
int
add_set_language_command ()
{
const char **language_names;
language_names = new const char *[6];
const char **language_names_p = language_names;
language_names_p++;
language_names_p++;
language_names_p++;
return (language_names_p) - (language_names+3);
}
This should just return 0; Which was able to be done in GCC 4.4.7.
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #16 from CVS Commits --- The master branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:546ecb0054af302acf0839c7f3eb78598f8c0672 commit r12-3375-g546ecb0054af302acf0839c7f3eb78598f8c0672 Author: Xionghu Luo Date: Mon Sep 6 20:22:50 2021 -0500 rs6000: Expand fmod and remainder when built with fast-math [PR97142] fmod/fmodf and remainder/remainderf could be expanded instead of library call when fast-math build, which is much faster. fmodf: fdivs f0,f1,f2 frizf0,f0 fnmsubs f1,f2,f0,f1 remainderf: fdivs f0,f1,f2 frinf0,f0 fnmsubs f1,f2,f0,f1 SPEC2017 Ofast P8LE: 511.povray_r +1.14%, 526.blender_r +1.72% gcc/ChangeLog: 2021-09-07 Xionghu Luo PR target/97142 * config/rs6000/rs6000.md (fmod3): New define_expand. (remainder3): Likewise. gcc/testsuite/ChangeLog: 2021-09-07 Xionghu Luo PR target/97142 * gcc.target/powerpc/pr97142.c: New test.
[Bug testsuite/101902] [12 regression] g++.dg/warn/uninit-1.C has excess errors after r12-2898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101902 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Hans-Peter Nilsson --- (In reply to Jan Hubicka from comment #1) > Hi, > i am testing > > diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c > index 5d7bc800419..d89ab5423cd 100644 > --- a/gcc/tree-ssa-uninit.c > +++ b/gcc/tree-ssa-uninit.c > @@ -641,7 +641,7 @@ maybe_warn_pass_by_reference (gcall *stmt, wlimits > ) > wlims.always_executed = false; > >/* Ignore args we are not going to read from. */ > - if (gimple_call_arg_flags (stmt, argno - 1) & EAF_UNUSED) > + if (gimple_call_arg_flags (stmt, argno - 1) & (EAF_UNUSED | > EAF_NOREAD)) > continue; > >tree arg = gimple_call_arg (stmt, argno - 1); Looks like Jan committed this as e12946df34c997e96c3bc7eb5a0247e889ddb7ea but forgot to mark the commit-log. I'm closing this.
[Bug target/102115] symbol address eliminated by the xtensa size optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102115 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added CC||jcmvbkbc at gcc dot gnu.org Last reconfirmed||2021-09-07 Assignee|unassigned at gcc dot gnu.org |jcmvbkbc at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from jcmvbkbc at gcc dot gnu.org --- Thanks for the report and analysis. The following part needs a bit of explanation: After the 64a54505ec8249178b9767d1420354f8eb55de50, using -Os on x86_64-w64-mingw32 *may* result in missing function symbol in the example test.ii attached if the symbol's address can be compressed into small number accepted by the movi + slli. It's not about the address that corresponds to the symbol in the target code (e.g. in the attached example the target addresses are all unknown), but about the RTX node address that describes the symbol inside the compiler. That makes this bug hard to reproduce.
[Bug tree-optimization/102134] [12 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102134 --- Comment #10 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:74cb45e67d14624c3e2fafa99a8920d1866a5f0c commit r12-3372-g74cb45e67d14624c3e2fafa99a8920d1866a5f0c Author: Roger Sayle Date: Mon Sep 6 22:48:53 2021 +0100 Correct implementation of wi::clz As diagnosed with Jakub and Richard in the analysis of PR 102134, the current implementation of wi::clz has incorrect/inconsistent behaviour. As mentioned by Richard in comment #7, clz should (always) return zero for negative values, but the current implementation can only return 0 when precision is a multiple of HOST_BITS_PER_WIDE_INT. The fix is simply to reorder/shuffle the existing tests. 2021-09-06 Roger Sayle gcc/ChangeLog * wide-int.cc (wi::clz): Reorder tests to ensure the result is zero for all negative values.
[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 --- Comment #3 from Sam James --- This appears to work fine (cannot reproduce the ICE) with GCC 12 at 1bc66017c118229a101f0a2c097a9c209f777883: ``` $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/s390-ibm-linux-gnu/12.0.0/lto-wrapper Target: s390-ibm-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-12.0.0_pre/work/gcc-12.0.0_pre/configure --host=s390-ibm-linux-gnu --build=s390-ibm-linux-gnu --prefix=/usr --bindir=/usr/s390-ibm-linux-gnu/gcc-bin/12.0.0 --includedir=/usr/lib/gcc/s390-ibm-linux-gnu/12.0.0/include --datadir=/usr/share/gcc-data/s390-ibm-linux-gnu/12.0.0 --mandir=/usr/share/gcc-data/s390-ibm-linux-gnu/12.0.0/man --infodir=/usr/share/gcc-data/s390-ibm-linux-gnu/12.0.0/info --with-gxx-include-dir=/usr/lib/gcc/s390-ibm-linux-gnu/12.0.0/include/g++-v12 --with-python-dir=/share/gcc-data/s390-ibm-linux-gnu/12.0.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 12.0.0_pre p2, commit 1bc66017c118229a101f0a2c097a9c209f777883' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20210906 (experimental) (Gentoo 12.0.0_pre p2, commit 1bc66017c118229a101f0a2c097a9c209f777883) ```
[Bug tree-optimization/102216] False positive warray-bounds with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > The problem is dead code: > language_names_p_9 = [(void *)_4 + 24B]; > MEM[(const char * *)_4 + 24B] = ""; > MEM[(const char * *)_4 + 32B] = ""; > MEM[(const char * *)_4 + 40B] = 0B; > _2 = _4 + 40; > D.50907._M_comp = compare_cstrings; > __comp = D.50907; > if (_2 != language_names_p_9) > goto ; [53.47%] > else > goto ; [46.53%] > >[local count: 574129759]: > _15 = _2 - language_names_p_9; > _16 = _15 /[ex] 8; > > ... > _22 = _2 - language_names_p_9; I have a (hack) patch which removes the first if statement but still does not fold _15 and _22.
[Bug c++/102223] no warning whel calling member function on dangling reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223
--- Comment #1 from Federico Kircheis ---
Sorry, I copied the wrong snippet, it should have been
#include
struct s{
s() noexcept;
~s();
int value() const noexcept;
};
s foo() noexcept;
int bar(){
const auto& v = std::move(foo());
int res = v.value();
return res;
}
As reference: https://godbolt.org/z/h31Trbsx6
[Bug c++/102223] New: no warning whel calling member function on dangling reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223
Bug ID: 102223
Summary: no warning whel calling member function on dangling
reference
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Consider this code-snippet
struct s{
s() noexcept;
~s();
int value() const noexcept;
};
s foo() noexcept;
int bar(){
const auto& v = static_cast(foo());
int res = v.value();
return res;
}
Normally life-extension would kick in, but because we added an unnecessary
static_cast, it does not kick in and v is a dangling reference.
GCC does not emit any warning
[Bug libfortran/102111] Segfault with associate to derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102111 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-06 Keywords||wrong-code --- Comment #3 from anlauf at gcc dot gnu.org --- I get a memory corruption on x86_64-pc-linux-gnu when adding a print as in comment#1. valgrind complains about: Invalid free() / delete / delete[] / realloc() So I guess it is not (fully) fixed yet.
[Bug c/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 --- Comment #2 from Sam James --- (In reply to Sam James from comment #0) > The issue was originally observed on a native s390 machine > (s390-ibm-linux-gnu) but I ended up minimising the ICE using cvise via > cross. I hit the issue when building squashfs-tools-4.5. It does not occur > with -march=native. > There aren't that many differences between -march=z10 and -march=native seemingly, but it appears -mzarch triggers it.
[Bug c++/96645] [9/10/11/12 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Eyal Rozenberg changed:
What|Removed |Added
CC||eyalroz1 at gmx dot com
--- Comment #12 from Eyal Rozenberg ---
(In reply to Jason Merrill from comment #8)
> We cannot correctly resolve is_nothrow_constructible until we've parsed
> the DMI. Given that, we have three options:
>
> 1) Conservatively say no.
> 2) Optimistically guess yes.
> 3) Non-SFINAE error.
>
> ("We" in this sentence is the C++ standard.)
But in this page, "we" is the compiler. IIUC, the standard does not allow for
determing is_nothrow_constructible. Am I correct? If that really is the
case, shouldn't the compiler emit an error saying that?
Alternatively, when not following the standard strictly, why should it not be
option (4.): Ignore the official restriction on determining (nothrow)
constructibility, make a best-effort attempt to determine it anyway ( which in
this example should succeed), and report failure otherwise.
?
> PR81359 changed our behavior from 3 to 1.
I searched that bug page for the rationale, and couldn't quite get it.
[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199 --- Comment #6 from Eyal Rozenberg --- (In reply to Jonathan Wakely from comment #4) > See PR 96645 and PR 101227 Ok. But does that explain why defining an explicit constructor cause g++ to accept the class as default-constructible?
[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199 --- Comment #5 from Eyal Rozenberg --- (In reply to Jonathan Wakely from comment #4) > See PR 96645 and PR 101227 Ok, I
[Bug c/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 --- Comment #1 from Sam James --- Created attachment 51418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51418=edit build.log from compiling squashfs-tools-4.5
[Bug c/102222] New: ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: ICE on s390 (internal compiler error: in extract_insn,
at recog.c:2770)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sam at gentoo dot org
Target Milestone: ---
Originally reported downstream at https://bugs.gentoo.org/811867.
This is my first time filing an ICE bug so let me know if I've messed something
up.
The issue was originally observed on a native s390 machine (s390-ibm-linux-gnu)
but I ended up minimising the ICE using cvise via cross. I hit the issue when
building squashfs-tools-4.5. It does not occur with -march=native.
I've managed to minimise the crasher to:
```
$ cat unsquash-1.i
struct squashfs_reg_inode_header_1 read_inode_inode;
read_inode_val;
struct squashfs_reg_inode_header_1 {
int file_size : 32
} __attribute__((packed)) read_inode() {
read_inode_inode.file_size = read_inode_val;
}
```
It can be induced via:
```
$ s390-ibm-linux-gnu-gcc -O2 -pipe -march=z10 unsquash-1.i
unsquash-1.i:2:1: warning: data definition has no type or storage class
2 | read_inode_val;
| ^~
unsquash-1.i:2:1: warning: type defaults to ‘int’ in declaration of
‘read_inode_val’ [-Wimplicit-int]
unsquash-1.i:5:1: warning: no semicolon at end of struct or union
5 | } __attribute__((packed)) read_inode() {
| ^
unsquash-1.i: In function ‘read_inode’:
unsquash-1.i:7:1: error: unrecognizable insn:
7 | }
| ^
(insn 9 8 10 2 (set (strict_low_part (reg:SI 66))
(mem/c:SI (plus:SI (reg/f:SI 64)
(const_int 4 [0x4])) [1 read_inode_val+0 S4 A32]))
"unsquash-1.i":6:30 -1
(nil))
during RTL pass: vregs
unsquash-1.i:7:1: internal compiler error: in extract_insn, at recog.c:2770
0x7fa3a9bb680c __libc_start_main
../csu/libc-start.c:332
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/92065] [9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #32 from anlauf at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #29) > r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e fixed it. This fix has been backported to all open branches. I verified that the ICE is now gone for the testcae in comment#0. Closing this PR. Please reopen if there is something that has been missed.
[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46991 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Pushed the fix by Paul to remaining open branches, but missed that the PR number was off due to a typo. Closing. Thanks for the report!
[Bug fortran/99819] [9 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from anlauf at gcc dot gnu.org --- Pushed fix by Paul to all open branches. Closing. Thanks for the report!
[Bug c++/46691] Null pointer in template deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c8cd1acae4c26929400fae0d7fb17cfef8c15be0 commit r9-9712-gc8cd1acae4c26929400fae0d7fb17cfef8c15be0 Author: Paul Thomas Date: Thu May 6 14:41:33 2021 +0100 Fortran: Assumed and explicit size class arrays [PR46691/99819]. 2021-05-06 Paul Thomas gcc/fortran/ChangeLog PR fortran/46691 PR fortran/99819 * class.c (gfc_build_class_symbol): Remove the error that disables assumed size class arrays. Class array types that are not deferred shape or assumed rank are given a unique name and placed in the procedure namespace. * trans-array.c (gfc_trans_g77_array): Obtain the data pointer for class arrays. (gfc_trans_dummy_array_bias): Suppress the runtime error for extent violations in explicit shape class arrays because it always fails. * trans-expr.c (gfc_conv_procedure_call): Handle assumed size class actual arguments passed to non-descriptor formal args by using the data pointer, stored as the symbol's backend decl. gcc/testsuite/ChangeLog PR fortran/46691 PR fortran/99819 * gfortran.dg/class_dummy_6.f90: New test. * gfortran.dg/class_dummy_7.f90: New test. (cherry picked from commit a2c593009fef1564dbef2237ee71e9fd08f5361e)
[Bug fortran/99819] [9 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c8cd1acae4c26929400fae0d7fb17cfef8c15be0 commit r9-9712-gc8cd1acae4c26929400fae0d7fb17cfef8c15be0 Author: Paul Thomas Date: Thu May 6 14:41:33 2021 +0100 Fortran: Assumed and explicit size class arrays [PR46691/99819]. 2021-05-06 Paul Thomas gcc/fortran/ChangeLog PR fortran/46691 PR fortran/99819 * class.c (gfc_build_class_symbol): Remove the error that disables assumed size class arrays. Class array types that are not deferred shape or assumed rank are given a unique name and placed in the procedure namespace. * trans-array.c (gfc_trans_g77_array): Obtain the data pointer for class arrays. (gfc_trans_dummy_array_bias): Suppress the runtime error for extent violations in explicit shape class arrays because it always fails. * trans-expr.c (gfc_conv_procedure_call): Handle assumed size class actual arguments passed to non-descriptor formal args by using the data pointer, stored as the symbol's backend decl. gcc/testsuite/ChangeLog PR fortran/46691 PR fortran/99819 * gfortran.dg/class_dummy_6.f90: New test. * gfortran.dg/class_dummy_7.f90: New test. (cherry picked from commit a2c593009fef1564dbef2237ee71e9fd08f5361e)
[Bug fortran/99125] [9 Regression] ICE: gimplification failed (gimplify.c:15068)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from anlauf at gcc dot gnu.org --- Should be fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 93925, which changed state. Bug 93925 Summary: Invalid memory reference upon call of a routine taking a procedure pointer as argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Should be fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from anlauf at gcc dot gnu.org --- Should be fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/99125] [9 Regression] ICE: gimplification failed (gimplify.c:15068)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3e59c3c6f4c4f42a158d8ab936c995754bf22dee commit r9-9711-g3e59c3c6f4c4f42a158d8ab936c995754bf22dee Author: Paul Thomas Date: Sat Mar 13 11:39:57 2021 + Fortran: Fix for class defined operators [PR99125]. 2021-03-13 Paul Thomas gcc/fortran PR fortran/99125 * trans-array.c (gfc_conv_expr_descriptor): For deferred length length components use the ss_info string length instead of gfc_get_expr_charlen. Make sure that the deferred string length is a variable before assigning to it. Otherwise use the expr. * trans-expr.c (gfc_conv_string_length): Make sure that the deferred string length is a variable before assigning to it. gcc/testsuite/ PR fortran/99125 * gfortran.dg/alloc_deferred_comp_1.f90: New test. (cherry picked from commit 7987beec679898cfa75839551d55ae5234a216bd)
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:49cefbec30499da06f90912090bcc5eabdfefa32 commit r9-9710-g49cefbec30499da06f90912090bcc5eabdfefa32 Author: Paul Thomas Date: Wed Jan 27 11:34:02 2021 + Fortran: Fix ICE due to elemental procedure pointers [PR93924/5]. 2021-01-27 Paul Thomas gcc/fortran PR fortran/93924 PR fortran/93925 * trans-expr.c (gfc_conv_procedure_call): Suppress the call to gfc_conv_intrinsic_to_class for unlimited polymorphic procedure pointers. (gfc_trans_assignment_1): Similarly suppress class assignment for class valued procedure pointers. gcc/testsuite/ PR fortran/93924 PR fortran/93925 * gfortran.dg/proc_ptr_52.f90 : New test. (cherry picked from commit 4225af228b5d52e8d7593dea49584c91b4bc2e1f)
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:49cefbec30499da06f90912090bcc5eabdfefa32 commit r9-9710-g49cefbec30499da06f90912090bcc5eabdfefa32 Author: Paul Thomas Date: Wed Jan 27 11:34:02 2021 + Fortran: Fix ICE due to elemental procedure pointers [PR93924/5]. 2021-01-27 Paul Thomas gcc/fortran PR fortran/93924 PR fortran/93925 * trans-expr.c (gfc_conv_procedure_call): Suppress the call to gfc_conv_intrinsic_to_class for unlimited polymorphic procedure pointers. (gfc_trans_assignment_1): Similarly suppress class assignment for class valued procedure pointers. gcc/testsuite/ PR fortran/93924 PR fortran/93925 * gfortran.dg/proc_ptr_52.f90 : New test. (cherry picked from commit 4225af228b5d52e8d7593dea49584c91b4bc2e1f)
[Bug tree-optimization/96563] Failure to optimize loop with condition to simple arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96563 --- Comment #3 from Gabriel Ravier --- It seems like GCC does better for the unrolled case as of now on trunk and seemingly since GCC 11, though the operation is done in a different way due to `((unsigned)x <= 9) ? 8 : 4;` being expanded differently, which does seem interesting w.r.t. perhaps optimizing `(((unsigned)x <= 9) * 4) + 4` to it or the other way around.
[Bug c++/102201] Accepts invalid C++98 with nested class and sizeof of outer's non-static field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102201 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- DR613 is CD1 so yes it is included in C++98/C++03. clang must have decided CD1's are not included ...
[Bug fortran/93794] [9 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93794 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug tree-optimization/98350] Reassociation breaks FMA chains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98350 Andrew Pinski changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 70912 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/70912] reassociation width needs to be aware of FMA, width of expression, and other architectural details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70912 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- This is a dup of bug 98350. *** This bug has been marked as a duplicate of bug 98350 ***
[Bug fortran/93794] [9 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93794 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5bfb794ae1bef72e251b5aa7274e79b3034bb1bc commit r9-9709-g5bfb794ae1bef72e251b5aa7274e79b3034bb1bc Author: Paul Thomas Date: Fri Jan 8 10:15:22 2021 + Fortran: Allow pointer deferred length associate selectors. [PR93794] 2021-01-05 Paul Thomas gcc/fortran PR fortran/93794 * trans-expr.c (gfc_conv_component_ref): Remove the condition that deferred character length components only be allocatable. gcc/testsuite/ PR fortran/93794 * gfortran.dg/deferred_character_35.f90 : New test. (cherry picked from commit 21c1a30fc73105af50c5e717cb99dc3becabf8fa)
[Bug tree-optimization/56547] missed opportunity for FMA with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 --- Comment #7 from Andrew Pinski --- >Not sure yet whether this is actually target specific. It is not.
[Bug tree-optimization/56547] [SH] missed opportunity for fmac with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 Andrew Pinski changed: What|Removed |Added CC||mkretz at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- *** Bug 102219 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102219] fast-math inhibits fp contraction for a + b * a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102219 --- Comment #2 from Andrew Pinski --- Actually it is a dup of bug 56547. *** This bug has been marked as a duplicate of bug 56547 ***
[Bug tree-optimization/56547] [SH] missed opportunity for fmac with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 Andrew Pinski changed: What|Removed |Added CC||chtz at informatik dot uni-bremen. ||de --- Comment #5 from Andrew Pinski --- *** Bug 98429 has been marked as a duplicate of this bug. ***
[Bug middle-end/98429] Some FMA expressions are evaluated less efficiently when -ffast-math is active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98429 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 56547. *** This bug has been marked as a duplicate of bug 56547 ***
[Bug tree-optimization/91687] Fused multiply subtract not generated when same operand appears in multiplication and subtraction and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91687 Bug 91687 depends on bug 86999, which changed state. Bug 86999 Summary: missed FMA optimization with -fassociative-math https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/56547] [SH] missed opportunity for fmac with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 Andrew Pinski changed: What|Removed |Added CC||asd0025 at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 86999 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/86999] missed FMA optimization with -fassociative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- Dup of bug 56547. *** This bug has been marked as a duplicate of bug 56547 ***
[Bug middle-end/98429] Some FMA expressions are evaluated less efficiently when -ffast-math is active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98429 Andrew Pinski changed: What|Removed |Added CC||mkretz at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 102219 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102219] fast-math inhibits fp contraction for a + b * a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102219 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 98429. *** This bug has been marked as a duplicate of bug 98429 ***
[Bug c++/102221] New: Missed optimizations for algorithms over std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
Bug ID: 102221
Summary: Missed optimizations for algorithms over
std::unique_ptr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Sorting/heaping/etc. an array/vector of unique_ptr generates worse codegen than
the equivalent code on an array of raw pointers. This is a missed optimization,
as the operations involved should just be mere swaps.
For instance:
#include
#include
#if defined(SMART)
using ptr = std::unique_ptr;
#else
using ptr = int*;
#endif
void f()
{
extern ptr *data;
const auto cmp = [](const auto , const auto ) { return *a < *b; };
std::sort(data, data+1000, cmp);
}
https://gcc.godbolt.org/z/7zPYxr9q7
This generates quite some extra code (including calls to operator delete); the
result is that such a sort is slower than the countepart with a raw pointer.
[Bug c++/102220] New: Conversion from cv void* to object-type* not rejected during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102220
Bug ID: 102220
Summary: Conversion from cv void* to object-type* not rejected
during constant evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/ecYjGsWo7.
```C++
#include
int main() {
[i=0]() consteval /*mutable*/ {
++*(int*)(void*)
assert(i == 1);
}();
}
```
A minimal reproduction:
```C++
int main() {
[i=0]() consteval {
(void)+*(const int*)(const void*)
}();
}
```
Discovered at
https://cpplang.slack.com/archives/C263VAF2B/p1630942490163700?thread_ts=1630937296.159200=C263VAF2B.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #13 from Alexander Monakov --- Sergei Trofimovich made substantial progress on diagnosing this on Gentoo side, and according to his findings the crash is due to reading stack canary from a wrong location. This indicates that the bug is not in GCC, but in the CPU or maybe the kernel. Please see comments 73 and 74 in the Gentoo bugreport: https://bugs.gentoo.org/724314#c73
[Bug c++/92505] Using mutable in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- Comment #4 from Arthur O'Dwyer ---
Confirmed; the test case can be as simple as
// https://godbolt.org/z/M9rf31qqq
struct S { mutable int m; };
static_assert(S{42}.m == 42);
(Removing the "mutable" keyword makes GCC happy.)
[Bug tree-optimization/102219] New: fast-math inhibits fp contraction for a + b * a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102219
Bug ID: 102219
Summary: fast-math inhibits fp contraction for a + b * a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mkretz at gcc dot gnu.org
Target Milestone: ---
Test case (compiled with -O2 -mfma):
[[gnu::optimize("fast-math")]]
float f(float a, float b)
{
return a + b * a;
}
float g(float a, float b)
{
return a + b * a;
}
f is not contracted to an fma, while g is.
Wild guess: GCC considers a transformation to (1 + b) * a and determines too
late that (1 + b) * a is better transformed to a + b * a (note that `return (1
+ b) * a` also emits vmulss, vaddss like f above and also doesn't contract to
an FMA even though it could/should). Maybe (1 + b) * a should be contracted to
fma(a, b, a) with fast-math, in general?
[Bug c++/102201] Accepts invalid C++98 with nested class and sizeof of outer's non-static field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102201 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- It's accepted since: C++ DR 613 C++ DR 613 * semantics.c (finish_non_static_data_member): Allow such references without an associated object in sizeof/decltype/alignof. From-SVN: r145375 (and SVN r145620 on the gcc-4.4 branch). Presumably treating it as a DR was intentional.
[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199 --- Comment #4 from Jonathan Wakely --- See PR 96645 and PR 101227
[Bug c++/100470] std::is_nothrow_move_constructible incorrect behavior for explicitly defaulted members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100470 Jonathan Wakely changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Jonathan Wakely --- This is a compiler bug, the library trait just asks the compiler.
[Bug libstdc++/51452] [DR 2116] is_nothrow_.*constructible bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #17 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #14) > This is http://cplusplus.github.com/LWG/lwg-active.html#2116 so let's > suspend this. Updated link: https://wg21.link/lwg2116
[Bug tree-optimization/101555] Compile slowdown in tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555 Richard Biener changed: What|Removed |Added Summary|[12 Regression] Compile |Compile slowdown in tree |slowdown in tree PRE|PRE Target Milestone|12.0|--- Keywords|needs-bisection | --- Comment #4 from Richard Biener --- Meanwhile GCC 12 seems to be as fast as GCC 11 (again). Still PRE is slow, in this case the profile seems to be mostly alias walk related.
[Bug target/102218] New: 128-bit atomic compare and exchange does not honor memory model on AArch64 and Arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218
Bug ID: 102218
Summary: 128-bit atomic compare and exchange does not honor
memory model on AArch64 and Arm
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
AArch64 and Arm libatomic do no support 128-bit atomics and so use the pthreads
fallback code on atomic operations.
The fallback code for atomic compare and exchange does the following
pre_seq_barrier (smodel);
magic = protect_start (mptr);
and for correctness relies on the target implementing pre_seq_barrier.
AArch64 and Arm however do not provide an implementation or pre_seq_barrier and
post_seq_barrier and the default implementations are just empty functions:
static inline void __attribute__((always_inline, artificial))
pre_seq_barrier(int model)
{
}
However for correctness on __ATOMIC_SEQ_CST a barrier needs to be emitted here
which isn't happening on any GCC version.
[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980 --- Comment #8 from Jürgen Reuter --- The actual workaround that I'm using (the code is from of our stale branches which recently became active again) is: [...] subroutine qn_string_set (qns, col) class(qn_string_t), intent(inout) :: qns class(col_t), dimension(:), intent(in), optional :: col class(col_t), allocatable :: col0 integer :: i do i = 1, qns%length if (present (col)) then col0 = col(i) call qns%qn(i)%set (col=col0) end if end do end subroutine qn_string_set end module quantum_numbers [...] This seems to work in our code, i.e. it compiles and it does what it should. But in the long run, would be great to get it fixed for gcc/gfortran 12.
[Bug middle-end/101551] [offloading] Differences in diagnostics etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101551 --- Comment #2 from Thomas Schwinge --- I've noticed that with an offloading-enabled build of GCC we're losing "note: in expansion of macro '[...]'" diagnostics. (Effectively '-ftrack-macro-expansion=0'?) For example, 'libgomp.oacc-c-c++-common/vred2d-128.c' with '-fopenacc -Wuninitialized' for a (default) GCC build without '--enable-offload-targets=[...]': [...] [...]/libgomp.oacc-c-c++-common/vred2d-128.c: In function ‘test1’: [...]/libgomp.oacc-c-c++-common/vred2d-128.c:34:8: warning: ‘t1’ is used uninitialized [-Wuninitialized] 34 | "acc loop vector reduction(+:t1) reduction(-:t2)") |^ ~ [...]/libgomp.oacc-c-c++-common/vred2d-128.c:11:14: note: ‘t1’ was declared here 11 | long i, j, t1, t2, t3;\ | ^~ [...]/libgomp.oacc-c-c++-common/vred2d-128.c:33:1: note: in expansion of macro ‘gentest’ 33 | gentest (test1, "acc parallel loop gang vector_length (128) firstprivate (t1, t2)", | ^~~ [...]/libgomp.oacc-c-c++-common/vred2d-128.c:34:8: warning: ‘t2’ is used uninitialized [-Wuninitialized] [...] ... vs. a GCC build with '--enable-offload-targets=[...]': [...] [...]/libgomp.oacc-c-c++-common/vred2d-128.c: In function ‘test1’: [...]/libgomp.oacc-c-c++-common/vred2d-128.c:34:8: warning: ‘t1’ is used uninitialized [-Wuninitialized] 34 | "acc loop vector reduction(+:t1) reduction(-:t2)") |^ ~ [...]/libgomp.oacc-c-c++-common/vred2d-128.c:11:14: note: ‘t1’ was declared here 11 | long i, j, t1, t2, t3;\ | ^~ [...]/libgomp.oacc-c-c++-common/vred2d-128.c:34:8: warning: ‘t2’ is used uninitialized [-Wuninitialized] [...] Note that an explicit '-foffload=disable' does not cure this.
[Bug target/89984] Extra register move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89984 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|NEW |RESOLVED --- Comment #4 from H.J. Lu --- Fixed for GCC 12.
[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980 --- Comment #7 from Jürgen Reuter --- Is anybody ever looked into this? Any updates?
[Bug target/89984] Extra register move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89984 --- Comment #3 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:652bef70d392f9541b12ef65b461009c8c8fd54a commit r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a Author: H.J. Lu Date: Sat Sep 4 08:28:00 2021 -0700 x86: Add non-destructive source to @xorsign3_1 Add non-destructive source alternative to @xorsign3_1 for AVX. gcc/ PR target/89984 * config/i386/i386-expand.c (ix86_split_xorsign): Use operands[2]. * config/i386/i386.md (@xorsign3_1): Add non-destructive source alternative for AVX. gcc/testsuite/ PR target/89984 * gcc.target/i386/pr89984-1.c: New test. * gcc.target/i386/pr89984-2.c: Likewise. * gcc.target/i386/xorsign-avx.c: Likewise.
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215
--- Comment #3 from Jakub Jelinek ---
Actually, looking at GCN, it is inline e.g. for both:
int
foo (int *p)
{
return __sync_val_compare_and_swap_4 (p, 1, 2);
}
int
bar (int *p)
{
int e = 1;
__atomic_compare_exchange_4 (p, , 2, 0, __ATOMIC_SEQ_CST,
__ATOMIC_SEQ_CST);
return e;
}
but for 1 or 2 byte atomics it is never inline:
int
foo (char *p)
{
return __sync_val_compare_and_swap_1 (p, 1, 2);
}
int
bar (char *p)
{
char e = 1;
__atomic_compare_exchange_1 (p, , 2, 0, __ATOMIC_SEQ_CST,
__ATOMIC_SEQ_CST);
return e;
}
The reason why foo in the second testcase works is libgcc/config/gcn/atomic.c
which defines __sync_{val,bool}_compare_and_swap_{1,2}.
So, either it should also define __atomic_compare_exchange_{1,2} perhaps with
calling __sync_val_compare_and_swap_{1,2} under the hood or the other way
around, or the backend somewhere needs to rewrite calls to
__atomic_compare_exchange_{1,2} into calls to __sync_*_compare_and_swap_{1,2}.
The reason why I've changed omp-expand is that by using __atomic_* APIs one can
use the user-requested memory models, and once the 5.1 atomics support is done,
there will be more - weak flag too, and user specified failure memory models.
[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 --- Comment #9 from Tobias Burnus --- I think my patch for moving the CFI<->GFC conversion to FE-generated code partially helps, https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578904.html However, I still see the following issues: integer :: y(-1:3,4,*) call test(y, num=0) -> subroutine test (x, num) integer :: x(..), num print *, shape(x) print *, size (x); if (size (x) /= -20) print *, 'ERROR: 1' 5 4 -1 0 That's unrelated to BIND(C) as there is no BIND(C). The problem is in gcc/fortran/trans-intrinsic.c, where gfc_conv_intrinsic_shape has code for AS_ASSUMED_RANK but gfc_conv_intrinsic_size does not. → Same result with BIND(C). Likewise for: print *, size (x, dim=3); if (size (x, dim=3) /= -1) print *, 'ERROR: 4' which also shows 0 instead of -1. – Same, except that the by-dimension results are not summed up. * * * 5 4 -1 ERROR 65 Expected is: 5, 4, 1 – the problem is that the last dimension is -1:-1. Looks as if gfc_conv_intrinsic_shape misses a check whether the argument is !attr.allocatable && !attr.pointer with symbol_attribute attr = gfc_expr_attr (expr); before assuming that the argument can be assumed size. → Same issue with BIND(C). * * * The following does not occur with BIND(C) - with my patch applied - but without BIND(C): ERROR: 25 5 4 -1 Another SHAPE issue. Issue: Last value should be '1' not '-1' as the argument is: allocate (B(-1:3,4,-1:-1)) The dump shows: test (, ); thus, the actual argument has the declared bounds – while in the callee is should have '1' as lower bound. I am not sure whether that's a caller or a callee problem. If handled in the caller, the following needs to work: subroutine bar(x) integer, allocatable :: x(..) print*, lbound(x) ! -> has allocated bounds call test(x) i.e. assumed-rank allocatable -> assumed-rank nonallocatable. In general, we have code which generates a temporary descriptor, e.g. for 'call test(b(:,:,:))'. (With C binding, we generate code which sets lbound to 0 in the caller.) → gfc_conv_procedure_call for the call handling / gfc_conv_expr_descriptor for the conversion. I wonder whether we need to set se->direct_byref = 0 in this case. Additionally failing: 5 4 -1 ERROR: 31 -1 ERROR 34 Same cause – just exposed via UBOUND() and UBOUND(…,dim=3). And also only without BIND(C).
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495 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 --- Created attachment 51415 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51415=edit gcc12-pr100495.patch The easiest fix seems to be to just remember the deleting dtor bodies and constexpr evaluating them, they are quite special anyway, as they are created by build_delete_destructor_body and essentially contain just two calls, so there is no user code in those and thus practically they aren't really clones of those user functions - they just call some other dtor fndecl (with the user code in it) and delete.
[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-06
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #12 from Andrew Pinski ---
p_6 = [130] + _1;
if ( [(void *) + 2B] > p_6)
Even this should be folded but is not currently:
void f (signed char i)
{
char d [260];
const char *p = [130];
p += i;
if (p == d + 2 || d + 257 == p)
__builtin_abort ();
}
I am thinking ptr_difference_const is not able to handle
[(void *) + 2B] correctly.
[Bug tree-optimization/94675] [9/10/11/12 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #20 from Andrew Pinski --- So on the trunk we get: c_len.0_1 = c_len; _2 = (long unsigned int) c_len.0_1; _6 = + _2; MEM [(struct pstream_t *)] = MEM [(struct pstream_t *) + 8B] = _6; _17 = (signed long) c_len.0_1; _11 = _17; _12 = (long unsigned int) _11; if (_12 > 6) goto ; [50.00%] else goto ; [50.00%] [local count: 483183820]: ps.D.4009.s = [(void *) + 7B]; [local count: 590558005]: Which is correct, I think the original testcase and the testcase in comment #1 and comment #11 are bogus and incorrect. There is always an out of bounds.
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #1) > So what did it do for __sync_val_compare_and_exchange_1 ? > Was that expanded inline, or do we have such entrypoint somewhere outside of > libatomic, something else? For nvptx, it became more exposed as libgomp.c-c++-common/reduction-16.c required __sync_val_compare_and_swap_16 – but only on PowerPC – such that config/nvptx/atomic.c was added, which in turn required __atomic_compare_exchange_n. Cf. (libgomp) r11-3182 and (libatomic + config/nvptx/nvptx.md) r11-3145 w/ PR96898 + PR96964. GCN: It seems as everything required so far was handled inline. I did note that one could create atomic testcases which are not handled and require __atomic_ / the nonexisting libatomic library. Regarding libatomic, it is currently disabled for gcn via libatomic/configure.tgt: *) # Who are you? UNSUPPORTED=1 ;; esac I don't know what's needed to support it, but for nvptx, it were only a few lines, cf. r11-3145
[Bug c++/101140] [modules] no matching function for call to ‘operator new(sizetype, void*)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101140 --- Comment #1 from ensadc at mailnesia dot com --- https://godbolt.org/z/EaPf3anxx
[Bug c++/101449] [modules] internal compiler error: in cxx_eval_call_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101449 --- Comment #1 from ensadc at mailnesia dot com --- https://godbolt.org/z/fMr9acG15
[Bug c++/102217] New: co_awaiting a temporary produced by ternary operator crashes (double-free)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102217
Bug ID: 102217
Summary: co_awaiting a temporary produced by ternary operator
crashes (double-free)
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: max at duempel dot org
Target Milestone: ---
Created attachment 51414
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51414=edit
Crashing demo program
When awaiting a coroutine task which is a temporary evaluated with the ternary
operator, GCC emits faulty code that destructs the task twice, leading to a
crash due to double free / use-after-free.
Tested with "gcc version 10.2.1 20210110 (Debian 10.2.1-6)" and "gcc version
11.2.0 (Debian 11.2.0-1)"
clang ("Debian clang version 11.0.1-2") is fine.
This crash bug can be worked around by assigning the result of the ternary
operator to a local variable first, and then co_await that variable.
In my demo program, the UniqueHandle destructor gets called twice with the same
contained pointer value; however, the UniqueHandle instance that gets
destructed first was never constructed.
ASan output with GCC 11:
==2==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600028 at
pc 0x5573042b18a9 bp 0x7ffdde510f60 sp 0x7ffdde510f58
READ of size 8 at 0x60600028 thread T0
#0 0x5573042b18a8 in Co::UniqueHandle >
>::~UniqueHandle() (/home/max/dl/a.out+0x28a8)
#1 0x5573042b1284 in FooC(FooC(bool)::_Z4FooCb.frame*) [clone .actor]
(/home/max/dl/a.out+0x2284)
#2 0x5573042b0582 in FooA(FooA()::_Z4FooAv.frame*) [clone .actor]
(/home/max/dl/a.out+0x1582)
#3 0x5573042b13a1 in FooC(FooC(bool)::_Z4FooCb.frame*) [clone .actor]
(/home/max/dl/a.out+0x23a1)
#4 0x5573042b00dd in main (/home/max/dl/a.out+0x10dd)
#5 0x7fa1f4ffbe39 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x27e39)
#6 0x5573042b01e9 in _start (/home/max/dl/a.out+0x11e9)
0x60600028 is located 8 bytes inside of 64-byte region
[0x60600020,0x60600060)
freed by thread T0 here:
#0 0x7fa1f55b6957 in operator delete(void*)
../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
#1 0x5573042b05b7 in FooA(FooA()::_Z4FooAv.frame*) [clone .actor]
(/home/max/dl/a.out+0x15b7)
previously allocated by thread T0 here:
#0 0x7fa1f55b5f57 in operator new(unsigned long)
../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x5573042b0af5 in FooA() (/home/max/dl/a.out+0x1af5)
[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96188 --- Comment #7 from Andrew Pinski --- (In reply to Martin Sebor from comment #6) > The example in comment #4 is due to the same problem/limitation in the > optimizer. The IL that triggers the warning is below: I am going to fix this issue as part of PR 102216.
[Bug target/102182] Runtime error for gcc.dg/torture/fp-int-convert-float16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102182 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Hongtao.liu --- Fixed in GCC12.
[Bug target/102182] Runtime error for gcc.dg/torture/fp-int-convert-float16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102182 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:93e6809459f34ca7b5928f1729246b2e9dfb3eb4 commit r12-3368-g93e6809459f34ca7b5928f1729246b2e9dfb3eb4 Author: liuhongt Date: Mon Sep 6 17:09:38 2021 +0800 Avoid FROM being overwritten in expand_fix. For the conversion from _Float16 to int, if the corresponding optab does not exist, the compiler will try the wider mode (SFmode here), but when floatsfsi exists but FAIL, FROM will be rewritten, which leads to a PR runtime error. gcc/ChangeLog: PR middle-end/102182 * optabs.c (expand_fix): Add from1 to avoid from being overwritten. gcc/testsuite/ChangeLog: PR middle-end/102182 * gcc.target/i386/pr101282.c: New test.
[Bug tree-optimization/102216] False positive warray-bounds with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-09-06 CC||pinskia at gcc dot gnu.org Keywords||diagnostic, ||missed-optimization --- Comment #1 from Andrew Pinski --- The problem is dead code: language_names_p_9 = [(void *)_4 + 24B]; MEM[(const char * *)_4 + 24B] = ""; MEM[(const char * *)_4 + 32B] = ""; MEM[(const char * *)_4 + 40B] = 0B; _2 = _4 + 40; D.50907._M_comp = compare_cstrings; __comp = D.50907; if (_2 != language_names_p_9) goto ; [53.47%] else goto ; [46.53%] [local count: 574129759]: _15 = _2 - language_names_p_9; _16 = _15 /[ex] 8; ... _22 = _2 - language_names_p_9; if (_22 > 128) goto ; [50.00%] else goto ; [50.00%] [local count: 287064879]: _23 = [(void *)_4 + 152B]; std::__insertion_sort > (language_names_p_9, _23, __comp); __comp_24 = MEM[(struct _Iter_comp_iter *)&__comp]; goto ; [100.00%] That is _22 (and _15) should be 16. I just fixed a similar issue today (but the patch did not fix this case). I will look into fixing this one tomorrow.
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495 --- Comment #5 from Jakub Jelinek --- Ah, for constructors this is likely a non-issue, because in_chrg etc. only appears on constructors of classes with virtual bases and such constructors are not constexpr.
[Bug tree-optimization/101394] [9 Regression] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 Richard Biener changed: What|Removed |Added Known to fail||10.3.0 Summary|[9/10 Regression] ICE on|[9 Regression] ICE on valid |valid code with -O2: SSA|code with -O2: SSA |corruption: Unable to |corruption: Unable to |coalesce ssa_names 10 and |coalesce ssa_names 10 and |19 which are marked as MUST |19 which are marked as MUST |COALESCE. |COALESCE. Priority|P3 |P2 Known to work||10.3.1
[Bug tree-optimization/101291] [10 Regression] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 Richard Biener changed: What|Removed |Added Known to fail||10.3.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||10.3.1 --- Comment #14 from Richard Biener --- Fixed.
[Bug tree-optimization/101009] [10 Regression] wrong code with "-O3 -fno-tree-sra"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101009 Richard Biener changed: What|Removed |Added Known to work||10.3.1 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||10.3.0 --- Comment #15 from Richard Biener --- Fixed.
[Bug tree-optimization/101394] [9/10 Regression] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:424737442fb7cd6ea8f0e63098c26cebdaf82a51 commit r10-10099-g424737442fb7cd6ea8f0e63098c26cebdaf82a51 Author: Richard Biener Date: Mon Jul 12 10:49:03 2021 +0200 tree-optimization/101394 - fix PRE full redundancy wrt abnormals This avoids adding a copy from an abnormal picked up from PHI translation much like we'd avoid inserting the translated expression on pred edges. 2021-07-12 Richard Biener PR tree-optimization/101394 * tree-ssa-pre.c (do_pre_regular_insertion): Avoid inserting copies from abnormals for a full redundancy. * gcc.dg/torture/pr101394.c: New testcase. (cherry picked from commit 92343e0ba4d47f21ae20ffcb83d736bdbc15dae0)
[Bug tree-optimization/101291] [10 Regression] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:1a4075c0a43fff9fac9df91c3e83e3a1949b69ff commit r10-10098-g1a4075c0a43fff9fac9df91c3e83e3a1949b69ff Author: Richard Biener Date: Mon Jul 5 11:53:07 2021 +0200 middle-end/101291 - set loop copy of versioned loop This fixes the vectorizer loop versioning code failing to clear niter related info on the scalar loop as it assumed get_loop_copy would work even for the outermost loop. The patch makes that assumption hold by adjusting the loop versioning code. 2021-07-05 Richard Biener PR middle-end/101291 * cfgloopmanip.c (loop_version): Set the loop copy of the versioned loop to the new loop. (cherry picked from commit 38872c6c0db1b10b17d3913b277c499913208d0b)
[Bug tree-optimization/101173] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101173 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ac6efdd70779a3be748d11c3b03c08df9ce15dd7 commit r10-10097-gac6efdd70779a3be748d11c3b03c08df9ce15dd7 Author: Richard Biener Date: Wed Jun 23 09:59:28 2021 +0200 tree-optimization/101173 - fix interchange dependence checking This adjusts the loop interchange dependence checking to properly guard all dependence checks with DDR_REVERSED_P or its inverse. 2021-07-07 Richard Biener PR tree-optimization/101173 PR tree-optimization/101280 * gimple-loop-interchange.cc (tree_loop_interchange::valid_data_dependences): Properly guard all dependence checks with DDR_REVERSED_P or its inverse. * gcc.dg/torture/pr101173.c: New testcase. (cherry picked from commit e46ec6e243c704f0858d16af380a7d9c36fc4244)
[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101280 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ac6efdd70779a3be748d11c3b03c08df9ce15dd7 commit r10-10097-gac6efdd70779a3be748d11c3b03c08df9ce15dd7 Author: Richard Biener Date: Wed Jun 23 09:59:28 2021 +0200 tree-optimization/101173 - fix interchange dependence checking This adjusts the loop interchange dependence checking to properly guard all dependence checks with DDR_REVERSED_P or its inverse. 2021-07-07 Richard Biener PR tree-optimization/101173 PR tree-optimization/101280 * gimple-loop-interchange.cc (tree_loop_interchange::valid_data_dependences): Properly guard all dependence checks with DDR_REVERSED_P or its inverse. * gcc.dg/torture/pr101173.c: New testcase. (cherry picked from commit e46ec6e243c704f0858d16af380a7d9c36fc4244)
[Bug tree-optimization/101105] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:aed52ca415b635463116486865a2a55f947cf8c1 commit r10-10096-gaed52ca415b635463116486865a2a55f947cf8c1 Author: Richard Biener Date: Wed Jun 23 12:43:03 2021 +0200 tree-optimization/101105 - fix runtime alias test optimization We were ignoring DR_STEP for VF == 1 which is OK only in case the scalar order is preserved or both DR steps are the same. 2021-06-23 Richard Biener PR tree-optimization/101105 * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Only ignore steps when they are equal or scalar order is preserved. * gcc.dg/torture/pr101105.c: New testcase. (cherry picked from commit 50374fdacbd121bc4a61b073e559208ff61bee06)
[Bug tree-optimization/101009] [10 Regression] wrong code with "-O3 -fno-tree-sra"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101009 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:917a675ad57f21f575c86192b22b1cc6d3bfc23d commit r10-10095-g917a675ad57f21f575c86192b22b1cc6d3bfc23d Author: Richard Biener Date: Fri Jun 11 09:33:58 2021 +0200 middle-end/101009 - fix distance vector recording This fixes recording of distance vectors in case the DDR has just constant equal indexes. In that case we expect distance vectors with zero distances to be recorded which is what was done when any distance was computed for affine indexes. 2021-06-11 Richard Biener PR middle-end/101009 * tree-data-ref.c (build_classic_dist_vector_1): Make sure to set *init_b to true when we encounter a constant equal index pair. (compute_affine_dependence): Also dump the actual DR_REF. * gcc.dg/torture/pr101009.c: New testcase. (cherry picked from commit 336c41dbcb21740f8964021e157bc69ca547059b)
[Bug tree-optimization/102216] New: False positive warray-bounds with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216
Bug ID: 102216
Summary: False positive warray-bounds with -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
With a gcc build from commit 637dfcf43cf, I run into an incorrect Warray-bounds
(which causes a buildbreaker when building gdb, as reported here:
https://sourceware.org/pipermail/gdb/2021-September/049687.html ).
Reproducer minimized from gdb/language.c:
...
$ cat language.c
#include
static inline bool
compare_cstrings (const char *str1, const char *str2)
{
return str1 < str2;
}
void
add_set_language_command ()
{
static const char **language_names;
language_names = new const char *[6];
language_names[0] = "auto";
language_names[1] = "local";
language_names[2] = "unknown";
const char **language_names_p = language_names;
/* language_names_p == _names[0]. */
language_names_p++;
/* language_names_p == _names[1]. */
language_names_p++;
/* language_names_p == _names[2]. */
language_names_p++;
/* language_names_p == _names[3]. */
const char **sort_begin;
if (0)
sort_begin = _names[3];
else
sort_begin = language_names_p;
language_names[3] = "";
language_names[4] = "";
language_names[5] = nullptr;
std::sort (sort_begin, _names[5], compare_cstrings);
}
...
First with gcc-11:
...
$ g++-11 -x c++ -Werror -Wall -O2 -S language.c -Warray-bounds=1
$
...
Now with trunk:
...
$ g++ -x c++ -Werror -Wall -O2 -S language.c -Warray-bounds=1
In file included from
/home/vries/gcc_versions/devel/install/include/c++/12.0.0/algorithm:61,
from language.c:1:
In function ‘void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = const char**;
_Compare = __gnu_cxx::__ops::_Iter_comp_iter]’,
inlined from ‘void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = const char**;
_Compare = __gnu_cxx::__ops::_Iter_comp_iter]’ at
/home/vries/gcc_versions/devel/install/include/c++/12.0.0/bits/stl_algo.h:1960:31,
inlined from ‘void std::sort(_RAIter, _RAIter, _Compare) [with _RAIter =
const char**; _Compare = bool (*)(const char*, const char*)]’ at
/home/vries/gcc_versions/devel/install/include/c++/12.0.0/bits/stl_algo.h:4868:18,
inlined from ‘void add_set_language_command()’ at language.c:40:13:
/home/vries/gcc_versions/devel/install/include/c++/12.0.0/bits/stl_algo.h:1869:32:
error: array subscript 19 is outside array bounds of ‘void [48]’
[-Werror=array-bounds]
1869 | std::__insertion_sort(__first, __first + int(_S_threshold),
__comp);
|
~^~
language.c: In function ‘void add_set_language_command()’:
language.c:14:38: note: at offset 152 into object of size 48 allocated by
‘operator new []’
14 | language_names = new const char *[6];
| ^
cc1plus: all warnings being treated as errors
...
Now set 'if (0)' to 'if (1)':
...
$ g++ -x c++ -Werror -Wall -O2 -S language.c -Warray-bounds=1
$
...
So either the warning is incorrect (for this fairly trivial example), or
there's a compiler/std::sort bug and the warning is letting us known.
[Bug middle-end/101018] ICE when enabling OpenMP on a simple loop with SVE intrinsics (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018 --- Comment #2 from Andrew Pinski --- /* When adding a variable-sized variable, we have to handle all sorts of additional bits of data: the pointer replacement variable, and the parameters of the type. */ None of this code is expecting base types which have non-constants sizes
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215 --- Comment #1 from Jakub Jelinek --- So what did it do for __sync_val_compare_and_exchange_1 ? Was that expanded inline, or do we have such entrypoint somewhere outside of libatomic, something else?
