[Bug fortran/96012] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012 Martin Liška changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-07-01 --- Comment #1 from Martin Liška --- Started with r9-3522-gd0477233215e37de.
[Bug target/96015] New: [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Bug ID: 96015
Summary: [regression] gcc-10.1.0 miscompiles Python on hppa
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: dave.anglin at bell dot net, law at redhat dot com
Target Milestone: ---
Target: hppa2.0-unknown-linux-gnu
Originally reported as https://bugs.gentoo.org/729570 where gcc-10.1.0
miscompiles Python into generating invalid bytecode. I shrunk Python's code
into single file that illustrates the problem:
// $ cat bug_test.c
/*
The test is extracted from Python-3.9.0 miscompilation
on hppa2.0: https://bugs.gentoo.org/729570
Original bug happens as an invalid bytecode generation
due to bad results from 'long_richcompare(0x, 1, EQ)' calls.
Failure example:
$ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -O1 bug_test.c -o
good-bug
$ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -O2 bug_test.c -o
bad-bug
$ ./good-bug
long_richcompare(2, 1, EQ) = FALSE (expect FALSE)
$ ./bad-bug
long_richcompare(2, 1, EQ) = TRUE (expect FALSE)
*/
// We use '__attribute__((noipa));' aggressively to simulate
// unavailable function definitions from outside translation units.
static int cmp(int *lhs, int *rhs)
{
int sign = *lhs - *rhs;
// semantically this should be 'return 0;' but this condition is not
// supposed to trigger on our input data.
if (sign == 0) return 1;
return sign;
}
static int yes(void) __attribute__((noipa));
static int yes(void) { return 1; }
static int long_richcompare(int *self, int *other, int op)
__attribute__((noipa));
static int long_richcompare(int *self, int *other, int op)
{
int result;
if (!yes() || !yes())
return 0;
if (self == other)
result = 0;
else
result = cmp(self, other);
// has to force jump table
switch (op) {
// only 0 case is used on actual data
case 0: return (result == 0);
case 1: return 0;
case 3: return 0;
case 5: if (result == 0) return 1; else return 0;
default:
__builtin_unreachable();
}
}
#include
int main() {
int l = 2;
int r = 1;
int res = long_richcompare(&l, &r, 0);
printf("long_richcompare(2, 1, EQ) = %s (expect FALSE)\n", res ? "TRUE" :
"FALSE");
}
[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #1 from Sergei Trofimovich --- Created attachment 48814 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48814&action=edit bug_test.c Selfcontained example.
[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #2 from Sergei Trofimovich --- Happens both on gcc-10.1.0 and gcc from main development branch. Here is the example of -O1/-O2 difference: $ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie -fno-stack-protector -O1 bug_test.c -o good-bug $ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie -fno-stack-protector -O2 bug_test.c -o bad-bug $ ./good-bug long_richcompare(2, 1, EQ) = FALSE (expect FALSE) $ ./bad-bug long_richcompare(2, 1, EQ) = TRUE (expect FALSE) GCC was built as: $ hppa2.0-unknown-linux-gnu-gcc -v Reading specs from /home/slyfox/dev/git/gcc-hppa2.0/gcc/specs COLLECT_GCC=/home/slyfox/dev/git/gcc-hppa2.0/gcc/xgcc COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-hppa2.0/gcc/lto-wrapper Target: hppa2.0-unknown-linux-gnu Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=hppa2.0-unknown-linux-gnu --prefix=/home/slyfox/dev/git/gcc-hppa2.0/../gcc-hppa2.0-installed --with-sysroot=/usr/hppa2.0-unknown-linux-gnu --disable-bootstrap --enable-languages=c --disable-nls CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20200701 (experimental) (GCC)
[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #3 from Sergei Trofimovich --- Reproducible on both qemu-hppa and on real "PA8600 (PCX-W+) 9000/785/C3600" machine.
[Bug bootstrap/95940] [11 Regression] bootstrap broken by -Wmaybe-unintialized warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
Eric Botcazou changed:
What|Removed |Added
Summary|[11 Regression] |[11 Regression] bootstrap
|sparc64-linux bootstrap |broken by
|with gcc-9.3 broken |-Wmaybe-unintialized
||warnings
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
The first -Wmaybe-unintialized warning is issued for the read in this
statement:
SR.1076_294 = D.75512.D.16218.val[1];
in the following basic block:
[local count: 130803720]:
# SR.268_98 = PHI <_104(23), _75(39)>
D.75553 ={v} {CLOBBER};
D.75512 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_294 = D.75512.D.16218.val[1]; <<< warning
SR.1077_296 = D.75512.D.16218.val[2]; <<< warning
D.75512 ={v} {CLOBBER};
D.75513 ={v} {CLOBBER};
goto ; [100.00%]
Since D.75512 is clobbered just prior to the read from it I think the warning
is justified. Subsequent warnings follow a similar pattern:
[local count: 349243402]:
# SR.268_123 = PHI <_129(25), -1(41)>
D.75575 ={v} {CLOBBER};
D.75514 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_230 = D.75514.D.16218.val[1]; <<< warning
SR.1077_105 = D.75514.D.16218.val[2]; <<< warning
D.75514 ={v} {CLOBBER};
D.75515 ={v} {CLOBBER};
goto ; [100.00%]
...
[local count: 68586742]:
# SR.268_148 = PHI <_154(30), -1(40)>
D.75597 ={v} {CLOBBER};
D.75516 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_219 = D.75516.D.16218.val[1]; <<< warning
SR.1077_220 = D.75516.D.16218.val[2]; <<< warning
D.75516 ={v} {CLOBBER};
D.75517 ={v} {CLOBBER};
goto ; [100.00%]
--- Comment #5 from Martin Sebor ---
The first -Wmaybe-unintialized warning is issued for the read in this
statement:
SR.1076_294 = D.75512.D.16218.val[1];
in the following basic block:
[local count: 130803720]:
# SR.268_98 = PHI <_104(23), _75(39)>
D.75553 ={v} {CLOBBER};
D.75512 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_294 = D.75512.D.16218.val[1]; <<< warning
SR.1077_296 = D.75512.D.16218.val[2]; <<< warning
D.75512 ={v} {CLOBBER};
D.75513 ={v} {CLOBBER};
goto ; [100.00%]
Since D.75512 is clobbered just prior to the read from it I think the warning
is justified. Subsequent warnings follow a similar pattern:
[local count: 349243402]:
# SR.268_123 = PHI <_129(25), -1(41)>
D.75575 ={v} {CLOBBER};
D.75514 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_230 = D.75514.D.16218.val[1]; <<< warning
SR.1077_105 = D.75514.D.16218.val[2]; <<< warning
D.75514 ={v} {CLOBBER};
D.75515 ={v} {CLOBBER};
goto ; [100.00%]
...
[local count: 68586742]:
# SR.268_148 = PHI <_154(30), -1(40)>
D.75597 ={v} {CLOBBER};
D.75516 ={v} {CLOBBER};
xi ={v} {CLOBBER};
SR.1076_219 = D.75516.D.16218.val[1]; <<< warning
SR.1077_220 = D.75516.D.16218.val[2]; <<< warning
D.75516 ={v} {CLOBBER};
D.75517 ={v} {CLOBBER};
goto ; [100.00%]
--- Comment #6 from Eric Botcazou ---
> From the look of it, something is already miscompiled.
No, not at all, it's just warnings turned into errors.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.2 Keywords||wrong-code Summary|[regression] gcc-10.1.0 |[10/11 Regression] |miscompiles Python on hppa |gcc-10.1.0 miscompiles ||Python on hppa
[Bug libquadmath/96016] New: AArch64: enable libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016 Bug ID: 96016 Summary: AArch64: enable libquadmath Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: bule1 at huawei dot com Target Milestone: --- Target: AARCH64 Created attachment 48815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48815&action=edit patch for enable libquadmath in aarch64 Hi I would like to propose a way to enable libquadmath on aarch64. Currently aarch64 support quad precision float point with type "long double". However the libquadmath won't build even if we specify --enable-quadmath in the configure because it will check whether the target support type __float128 during the build configureation. The build process of libquadmath exit if the answer is no. According to the arm abi(https://c9x.me/compile/bib/abi-arm64.pdf) and some test cases I tried, I found that in aarch64, long double is equivalent to __float128 in x86. I happened need to use a quad-precision math library. So I cancled the hard limitation on detecting __float 128 type. After the change when it found the target is aarch64, a Macro is introduced to redefine long double as __float128. It turns out that the libquadmath can be build and works successfully on aarch64. Test have been conducted with random inputs on aarch64 and x86. The output on aarch64 is agree with the output on x86. One minor question of my solution is that aarch64 don't have __builtin_huge_valq built-in functions to define the HUGE_VALQ. I used the value in the original comment that clearly stated this might cause warning, which did happened during the build. I haven't found where and how does aarch64 define all these built-in const values. Any comment on this issue? The patch is attached. You are welcome to check and comment on the patch. Is it ok for trunk?
Re: How GCC treats ice-on-invalid-code?
> It's fine to file these ice-on-invalid bugs, but don't be surprised if > nobody has time to work on bugs that are only triggered by unrealistic > garbage input. Right, an ICE is a perfectly valid outcome for garbage input and there are hundreds of assertions in the compiler precisely for this purpose. -- Eric Botcazou
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Thank you for the report. What system do you use that can cross compile (and link) the test-case in order to run it in qemu?
[Bug libquadmath/96016] AArch64: enable libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016 --- Comment #1 from Andrew Pinski --- If long double is 128bit fp already, then glibc has full support of it. So you dont need libquadmath at all. It is only there if long double is not 128bit long double and glibc does not have support for the __float128 type.
[Bug libquadmath/96016] AArch64: enable libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016
--- Comment #2 from Bu Le ---
(In reply to Andrew Pinski from comment #1)
> If long double is 128bit fp already, then glibc has full support of it. So
> you dont need libquadmath at all. It is only there if long double is not
> 128bit long double and glibc does not have support for the __float128 type.
Can you elabrate more?
I tried this test case with libm which gives me an incorrected answer without
enough precision -f000--3ffd. What library does glibc
provides for quad math? Or maybe I configure the libm wrong?
#include
#include
int main(void)
{
long double ld = 0;
long double res;
long double pi = acos(-1);
int* i = (int*) &res;
i[0] = i[1] = i[2] = i[3] = 0xdeadbeef;
ld = pi/6;
res = sin(ld);
printf("sinq-1: %08x-%08x-%08x-%08x\n", i[0], i[1], i[2], i[3]);
}
/* { dg-output "sinq-1: af2139b8-fae7b900--3ffd\n" } */
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #5 from Sergei Trofimovich --- I ran the test in qemu-hppa (qemu user binary emulation) against Gentoo's hppa2.0 root system as: /usr/bin/qemu-hppa -L /usr/hppa2.0-unknown-linux-gnu/ "$@" where /usr/hppa2.0-unknown-linux-gnu/ is a hppa SYSROOT. Cross-compiler is generated with Gentoo's 'crossdev' tool as: # crossdev hppa2.0-unknown-linux-gnu The command builds cross-binutils, cross-gcc with --sysroot=/usr/hppa2.0-unknown-linux-gnu/ and puts glibc into /usr/hppa2.0-unknown-linux-gnu/. Full native root system is also at http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3-hppa2.0/ (stage3-hppa2.0-*.tar.bz2 tarballs). Should be good enough to be used for qemu-hppa as-is. I also plan to pass through the assembly dump this evening to get the idea where incorrect code got generated to spare you the debugging.
[Bug fortran/95829] Bogus error with additional blanks in type(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95829 --- Comment #2 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:624e60f080989fa57756575a0bb47a97748b52b8 commit r11-1753-g624e60f080989fa57756575a0bb47a97748b52b8 Author: Mark Eggleston Date: Tue Jun 23 11:01:28 2020 +0100 Fortran : Bogus error with additional blanks in type(*) PR95829 Checking for "* ) " instead of "*)" clears the bogus error. 2020-07-01 Steven G. Kargl gcc/fortran/ PR fortran/95829 * decl.c (gfc_match_decl_type_spec): Compare with "* ) " instead of "*)". 2020-07-01 Mark Eggleston gcc/testsuite/ PR fortran/95829 * gfortran.dg/pr95829.f90: New test.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #6 from Sergei Trofimovich --- Created attachment 48816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48816&action=edit bad-bug.S bad-bug.S is miscompiled file generated by main gcc (not clear what is wrong yet). Generated as: $gcc/xgcc -B$gcc/gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie -fno-stack-protector -O2 -S bug_test.c -o bad-bug.S
[Bug libquadmath/96016] AArch64: enable libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016 --- Comment #3 from Andreas Schwab --- You are computing the sine of (double)ld. If you want the sine of a long double value, you need to use the sinl function, also use acosl(-1) to compute pi in long double precision.
[Bug libquadmath/96016] AArch64: enable libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016 --- Comment #4 from Bu Le --- (In reply to Andreas Schwab from comment #3) > You are computing the sine of (double)ld. If you want the sine of a long > double value, you need to use the sinl function, also use acosl(-1) to > compute pi in long double precision. Oh, I see. Thanks for help.
[Bug gcov-profile/96010] std::make_tuple called over multiple lines reports lines as "not run"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96010 --- Comment #2 from Sergio Losilla --- On a side note: are these bug reports I am sending useful in their current form? Anything else that I can do to help? (Other than actually fixing them, because I feel awfully unqualified to even start looking...)
[Bug testsuite/96014] [11 regression] g++.dg/analyzer/pr94028.C excess errors starting with r11-1697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96014 --- Comment #4 from Jonathan Wakely --- I already sent a patch for g++.dg/analyzer/pr94028.C https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549202.html
[Bug target/96017] New: Powerpc suboptimal register spill in likely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
Bug ID: 96017
Summary: Powerpc suboptimal register spill in likely path
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: npiggin at gmail dot com
Target Milestone: ---
Target: powerpc64le-linux-gnu
Build: gcc version 9.2.1 20190909 (Debian 9.2.1-8)
-- test.c --
extern int foo;
extern void slowpath(int *);
int test(int *val)
{
int ret = foo;
if (__builtin_expect(*val != 0, 0))
slowpath(val);
return ret;
}
--
Compiling with -O2 gives the following asm. It seems possible for the fast path
case to avoid the stack frame by using a volatile register to save the val
argument in case the slow path needs it (or alternatively to save the load from
'foo', as r31 is used now, but that requires an extra register move on a
critical path for the return value). This should be smaller and faster code
even for the slow path too.
addis r2,r12,0
addir2,r2,0
lwz r9,0(r3)
addis r10,r2,0
ld r10,0(r10)
std r31,-8(r1)
stdur1,-48(r1)
lwa r31,0(r10)
cmpwi r9,0
bne 1f
addir1,r1,48
mr r3,r31
ld r31,-8(r1)
blr
nop
ori r2,r2,0
1: mflrr0
std r0,64(r1)
bl slowpath
nop
ld r0,64(r1)
addir1,r1,48
mr r3,r31
ld r31,-8(r1)
mtlrr0
blr
[Bug target/96017] Powerpc suboptimal register spill in likely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017 Bill Schmidt changed: What|Removed |Added CC||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Target Milestone|--- |9.4 Build|gcc version 9.2.1 20190909 | |(Debian 9.2.1-8)| Keywords||missed-optimization --- Comment #1 from Bill Schmidt --- Built with gcc version 9.2.1 20190909 (Debian 9.2.1-8) (moved from Build field).
[Bug target/96017] Powerpc suboptimal register spill in likely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017 Bill Schmidt changed: What|Removed |Added Target Milestone|9.4 |11.0
[Bug target/96017] Powerpc suboptimal register spill in likely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017 --- Comment #2 from Bill Schmidt --- Nick reports same behavior at -O3.
[Bug tree-optimization/96009] missed optimization with floating point operations and integer literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96009 --- Comment #2 from Marc Glisse --- Note that we don't do the optimization if you replace double with long either.
[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/96017] Powerpc suboptimal register spill in likely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017 --- Comment #3 from Nicholas Piggin --- This is possibly a more targeted and simpler test case for at least one of the problems in bug 84443. I would like to re-test that case after this one is solved if it's not an obvious duplicate.
[Bug fortran/95829] Bogus error with additional blanks in type(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95829 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:e025298cfcb1aae9d3ff674cdc1c4fb271cb2bdd commit r10-8405-ge025298cfcb1aae9d3ff674cdc1c4fb271cb2bdd Author: Mark Eggleston Date: Tue Jun 23 11:01:28 2020 +0100 Fortran : Bogus error with additional blanks in type(*) PR95829 Checking for "* ) " instead of "*)" clears the bogus error. 2020-07-01 Steven G. Kargl gcc/fortran/ PR fortran/95829 * decl.c (gfc_match_decl_type_spec): Compare with "* ) " instead of "*)". 2020-07-01 Mark Eggleston gcc/testsuite/ PR fortran/95829 * gfortran.dg/pr95829.f90: New test. (cherry picked from commit 624e60f080989fa57756575a0bb47a97748b52b8)
[Bug gcov-profile/96010] std::make_tuple called over multiple lines reports lines as "not run"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96010 --- Comment #3 from Martin Liška --- You're doing well, but as said, we have quite some GCOV issues that are quite similar to this one. And it seems quite low priority to me for now. You can inspire about what bugs we have here: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=gcov-profile&list_id=273005&product=gcc these starting with "[GCOV]".
Re: How GCC treats ice-on-invalid-code?
Eric Botcazou writes: >> It's fine to file these ice-on-invalid bugs, but don't be surprised if >> nobody has time to work on bugs that are only triggered by unrealistic >> garbage input. > > Right, an ICE is a perfectly valid outcome for garbage input and there are > hundreds of assertions in the compiler precisely for this purpose. You mean, an ICE is perfectly valid as the first (and obviously then only) error diagnostic the compiler prints for “garbage input”? If so, I don't think that's true. What counts as “garbage” seems a bit too subjective for that anyway. E.g. deleting a chunk of lines from a file creates something that makes no sense and might be considered garbage, but that can easily happen with a botched resolution to a merge conflict (or being too trigger-happy with git rerere :-)). I don't think it's OK for the compiler simply to crash without first giving the user an idea of what's wrong. I agree ICEs are mostly OK as a downstream effect of an error that has already been reported, but in the context of the quote above, those cases are error-recovery rather than ice-on-invalid-code. Thanks, Richard
[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95839 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7b3adfa7bb47e4ebde91634caa5a7e13175558f1 commit r11-1757-g7b3adfa7bb47e4ebde91634caa5a7e13175558f1 Author: Richard Biener Date: Fri Jun 26 11:18:19 2020 +0200 tree-optimization/95839 - teach SLP vectorization about vector inputs This teaches SLP analysis about vector typed externals that are fed into the SLP operations via lane extracting BIT_FIELD_REFs. It shows that there's currently no good representation for vector code on the SLP side so I went a half way and represent such vector externals uses always using a SLP permutation node with a single external SLP child which has a non-standard representation of no scalar defs but only a vector def. That works best for shielding the rest of the vectorizer from it. 2020-06-26 Richard Biener PR tree-optimization/95839 * tree-vect-slp.c (vect_slp_tree_uniform_p): Pre-existing vectors are not uniform. (vect_build_slp_tree_1): Handle BIT_FIELD_REFs of vector registers. (vect_build_slp_tree_2): For groups of lane extracts from a vector register generate a permute node with a special child representing the pre-existing vector. (vect_prologue_cost_for_slp): Pre-existing vectors cost nothing. (vect_slp_analyze_node_operations): Use SLP_TREE_LANES. (vectorizable_slp_permutation): Do not generate or cost identity permutes. (vect_schedule_slp_instance): Handle pre-existing vector that are function arguments. * gcc.dg/vect/bb-slp-pr95839-2.c: New testcase.
[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95839 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 95839, which changed state. Bug 95839 Summary: Failure to optimize addition of vector elements to vector addition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95839 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/96018] New: Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 Bug ID: 96018 Summary: Optimization issue with external HDF5 library Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: martin.schlipf at damnthespam dot com Target Milestone: --- Created attachment 48817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48817&action=edit Minimal example to demonstrate the issue. On a clean Ubuntu 20.04 with the following setup sudo apt-get update sudo apt-get install gfortran-10 sudo apt-get install libhdf5-dev the attached code produces an error when compiled with optimization gfortran-10 -O2 hdf5_bug.f90 -I/usr/include/hdf5/serial/ -L/usr/lib/x86_64-linux-gnu/ -lhdf5_serial_fortran As far as I can tell, the reason this appears is that the compiler fails to recognize that the function call in line 98 has side effects and optimizes it away. If you check the status of the error code, the issue disappears. Strangely, the exact same sequence of calls with a 2d array instead of a 3d one works fine.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-07-01 --- Comment #1 from Dominique d'Humieres --- Can you please provide the file(s) needed for use hdf5 ? TIA.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #2 from martin.schlipf at damnthespam dot com --- Well hdf5 is not developed by me, its a huge library. You can install it manually if you want (https://www.hdfgroup.org/solutions/hdf5/), but it is available on Ubuntu as mentioned sudo apt-get install libhdf5-dev There is probably a similar package for other linux distributions.
[Bug fortran/95829] Bogus error with additional blanks in type(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95829 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:a833478ca9898fe287ad423e5af8462938886758 commit r9-8710-ga833478ca9898fe287ad423e5af8462938886758 Author: Mark Eggleston Date: Tue Jun 23 11:01:28 2020 +0100 Fortran : Bogus error with additional blanks in type(*) PR95829 Checking for "* ) " instead of "*)" clears the bogus error. 2020-07-01 Steven G. Kargl gcc/fortran/ PR fortran/95829 * decl.c (gfc_match_decl_type_spec): Compare with "* ) " instead of "*)". 2020-07-01 Mark Eggleston gcc/testsuite/ PR fortran/95829 * gfortran.dg/pr95829.f90: New test. (cherry picked from commit 624e60f080989fa57756575a0bb47a97748b52b8)
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #3 from anlauf at gcc dot gnu.org --- You are not using HDF5's "native" Fortran interface directly, but a clumsy way with c_f_pointer to obscure your code. Any reason for that? Have you considered using RESHAPE for what you seem to try to get? Your code will run into issues if the dummy "array" is not contiguous. Also, I'd consider not checking a library's return code bad style. Also, can you give details on the exact compiler version and HDF5?
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #24 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:aa8b5ca0b540fde5890f3114f2d7076d5238fc2e commit r11-1759-gaa8b5ca0b540fde5890f3114f2d7076d5238fc2e Author: Christophe Lyon Date: Wed Jul 1 12:23:51 2020 + arm: Fix handler-align.c testcase [PR target/94743] This testcase triggers the new warning, so compile it with -mgeneral-regs-only. 2020-07-01 Christophe Lyon PR target/94743 gcc/testsuite/ * gcc.target/arm/handler-align.c: Add -mgeneral-regs-only.
[Bug c/96019] New: Optimization forgets non-default scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019 Bug ID: 96019 Summary: Optimization forgets non-default scalar_storage_order Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: arthur200126 at gmail dot com Target Milestone: --- Created attachment 48818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48818&action=edit test case The attached code uses a scalar_storage_order to access a byte field in big endian. On an x86-64 Windows system, the output without optimization, as expected, is "aabbccdd 1122". The output with optimization (Og) is "ddccbbaa 2211". The same happens on the https://gcc.godbolt.org/ site. With O0 a bswap can be found, but it is gone in -O1 and -Og. I was unable to find the responsible option by bisection on the godbolt instance, but that could just be a godbolt thing.
[Bug c/96019] Optimization forgets non-default scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Richard Biener --- I think Eric posted patches for this?
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #4 from martin.schlipf at damnthespam dot com --- Hdf5 doesn't have native support for complex datatypes, so we convert to real and write that it is a complex as an attribute. If you replace the conversion logic by an array instead of a pointer allocate(real_array(2,size(array,1),size(array,2),size(array,3))) reshape(transfer(array, real_array), shape(real_array)) it doesn't alert the behavior. I agree that the error code should be checked and in fact, I already started a merge request for that particular part. But for this bug report, I need to leave it away, because otherwise the compiler does the right thing. Finally, I reproduced it with gfortran 9.3.0 + hdf 1.12.0 and gfortran 10.0 + hdf 1.10.4. With older versions of gfortran 7.3.0 it does not appear.
[Bug fortran/95829] Bogus error with additional blanks in type(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95829 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:88b44ed719378a52e001a474bcf963ea4c4841b1 commit r8-10337-g88b44ed719378a52e001a474bcf963ea4c4841b1 Author: Mark Eggleston Date: Tue Jun 23 11:01:28 2020 +0100 Fortran : Bogus error with additional blanks in type(*) PR95829 Checking for "* ) " instead of "*)" clears the bogus error. 2020-07-01 Steven G. Kargl gcc/fortran/ PR fortran/95829 * decl.c (gfc_match_decl_type_spec): Compare with "* ) " instead of "*)". 2020-07-01 Mark Eggleston gcc/testsuite/ PR fortran/95829 * gfortran.dg/pr95829.f90: New test. (cherry picked from commit 624e60f080989fa57756575a0bb47a97748b52b8)
[Bug fortran/95829] Bogus error with additional blanks in type(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95829 markeggleston at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||markeggleston at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from markeggleston at gcc dot gnu.org --- Committed to master and backported.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #7 from Martin Liška --- There's ASM diff in between GCC 9 and 10 version: diff -u good.s bad.s --- good.s 2020-07-01 15:04:58.315839436 +0200 +++ bad.s 2020-07-01 15:04:30.684040487 +0200 @@ -30,7 +30,7 @@ .L15: ldi 0,%r28 .L3: -.L25: +.L26: ldw -84(%r30),%r2 ldw -60(%r30),%r4 ldw -56(%r30),%r3 @@ -39,16 +39,14 @@ .L22: bl yes,%r2 nop - comib,=,n 0,%r28,.L25 + comib,=,n 0,%r28,.L26 ldi 0,%r28 - comclr,<> %r4,%r5,%r0 - b,n .L23 comiclr,<< 5,%r3,%r0 - b,n .L24 -.L6: -.L23: - comib,<< 5,%r3,.L26 + b,n .L25 +.L12: + b .L3 ldi 1,%r28 +.L25: ldil L'.L8,%r28 ldo R'.L8(%r28),%r28 ldwx,s %r3(%r28),%r28 @@ -65,34 +63,6 @@ .word .L12 .end_brtab .text -.L12: - ldi 1,%r28 -.L26: - ldw -84(%r30),%r2 - ldw -60(%r30),%r4 - ldw -56(%r30),%r3 - bv %r0(%r2) - ldwm -64(%r30),%r5 -.L24: - ldil L'.L11,%r28 - ldo R'.L11(%r28),%r28 - ldwx,s %r3(%r28),%r28 - bv,n %r0(%r28) - .section.rodata - .align 4 -.L11: - .begin_brtab - .word .L14 - .word .L15 - .word .L6 - .word .L15 - .word .L6 - .word .L15 - .end_brtab - .text -.L14: - b .L3 - copy %r3,%r28 .EXIT .PROCEND .size long_richcompare, .-long_richcompare @@ -143,4 +113,4 @@ .EXIT .PROCEND .size main, .-main - .ident "GCC: (SUSE Linux) 9.3.1 20200406 [revision 6db837a5288ee3ca5ec504fbd5a765817e556ac2]" + .ident "GCC: (SUSE Linux) 10.1.1 20200625 [revision c91e43e9363bd119a695d64505f96539fa451bf2]"
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #8 from Martin Liška --- And first change happens in pr96015.c.299r.bbro which is likely a reason why a jump table is partially copied.
[Bug libstdc++/95992] chrono adding duration to time_point reports signed integer overflow with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95992 --- Comment #2 from Takatoshi Kondo --- Thank you. I understood that I should use appropriate types. I also understood why libc++ and libstdc++ behavior are different.
[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #9 from Florian Weimer --- Jonathan and I discussed this off this bug. The issue is the weak declaration of pthread_self in the libstdc++ headers. For glibc (at least since 2.1, possibly 2.0), there is no reason to have a weak declaration because the symbol lives in libc itself, so it is always available (both with static and dynamic linking). But if the symbol reference is weak and the symbol is not pulled in for some other reason, then the function is not linked in even if it is called.
[Bug c/96019] Optimization forgets non-default scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019 Eric Botcazou changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Eric Botcazou --- See the manual: Moreover, the use of type punning or aliasing to toggle the storage order is not supported; that is to say, a given scalar object cannot be accessed through distinct types that assign a different storage order to it.
[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989 --- Comment #10 from Jonathan Wakely --- I have a fix for std::this_thread::get_id() but we also need the same fix in and I'd rather refactor that first to only need to fix it in one place.
[Bug c/96019] Optimization forgets non-default scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019
--- Comment #3 from Richard Biener ---
So AFAIU
int main(int argc, char *argv[]) {
uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 };
SS instance;
memcpy (&instance, raw, sizeof (SS));
printf("%x, %x\n", instance.a, instance.b);
return 0;
}
would be OK(?)
[Bug target/96017] Powerpc suboptimal register spill in likely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #4 from Peter Bergner ---
To be pedantic, "val" is assigned r3, the incoming arg reg. The compiler
temporary that holds "*val" is assigned r9 which is a volatile register. The
only non-volatile in use is r31 which was assigned to hold "ret". Since "ret"
is live and used across both the fast and slow paths, it needs a non-volatile
register since it is live across the slowpath call. The load of foo occurs
early because foo is a global and could be modified by the slowpath call.
What we want is for "ret" to be assigned a volatile register for the fast path
and only use a non-volatile for the slowpath. That means we have to split the
live range before RA. Shrink wrapping is too late here to help us. We
basically want a function that looks like:
-- test.c --
extern int foo;
extern void slowpath(int *);
int test(int *val)
{
int ret = foo;
if (__builtin_expect(*val != 0, 0)) {
int tmp = ret;
slowpath(val);
ret = tmp;
}
return ret;
}
--
Here "ret" doesn't live across the call so can be assigned a volatile register
and "tmp" which is live across the call and needs the non-volatile register is
only live in the slowpath, so shrink-wrapping can optimize it.
Doing this by hand doesn't help, because the early optimizers (not sure which
ones, didn't look) optimize those copies away and we end up with the same code,
so we'd want something that maybe adds those copies just before RA?
That said, rewriting the code like the following does seem to give good code on
the fast path:
-- test.c --
extern int foo;
extern void slowpath(int *);
int test(int *val)
{
int ret = foo;
if (__builtin_expect(*val != 0, 0)) {
volatile int tmp = ret;
slowpath(val);
ret = tmp;
}
return ret;
}
--
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry test,.-test
lwz 10,0(3)
addis 9,2,.LC0@toc@ha
ld 9,.LC0@toc@l(9)
lwa 9,0(9)
cmpwi 0,10,0
bne 0,.L11
mr 3,9
blr
.p2align 4,,15
.L11:
mflr 0
std 0,16(1)
stdu 1,-48(1)
stw 9,32(1)
bl slowpath
nop
lwa 9,32(1)
addi 1,1,48
ld 0,16(1)
mr 3,9
mtlr 0
blr
[Bug c/96019] Optimization forgets non-default scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019
--- Comment #4 from Eric Botcazou ---
> So AFAIU
>
> int main(int argc, char *argv[]) {
> uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 };
> SS instance;
> memcpy (&instance, raw, sizeof (SS));
> printf("%x, %x\n", instance.a, instance.b);
> return 0;
> }
>
> would be OK(?)
Yes, this should work once the patch (or a variant thereof) I posted some time
ago to make memcpy a storage order barrier is installed. :-)
[Bug tree-optimization/96020] New: FRE uses not available def across EH edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96020
Bug ID: 96020
Summary: FRE uses not available def across EH edges
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
I failed to distill a small testcase like
int *q;
int main()
{
int *p = q;
int a = 1;
try {
a = *p;
} catch (...) {
int b = *p;
a += b;
}
__builtin_exit (a);
}
where a __cxa_begin_catch (_1); prevents CSE of the *p load across the EH
edge with -fnon-call-exceptions:
:
# VUSE <.MEM_4(D)>
p_5 = q;
# VUSE <.MEM_4(D)>
_7 = *p_5;
:
:
# VUSE <.MEM_4(D)>
_1 = __builtin_eh_pointer (1);
# .MEM_9 = VDEF <.MEM_4(D)>
__cxa_begin_catch (_1);
# VUSE <.MEM_9>
_10 = *p_5;
but for g++.dg/opt/pr92610.C and g++.dg/pr48633.C with for example -std=gnu++14
we can see it doing this:
:
_45 = MEM[(sizetype *)_28];
:
:
- _51 = MEM[(sizetype *)_28];
- _15 = _51 + 2;
+ _15 = _45 + 2;
_16 = _15 * 4;
operator delete [] (_28, _16);
resx 5
thereby ICEing with a new SSA verification piece I coded after directing
Martin to only consider the fallthru edge as insert location for the SSA
defs of an internally throwing stmt.
DOM is probably susceptible to this, too.
I'm not sure how to trigger a real-world case that would exhibit breakage
(for the above we're removing another trap on the EH handler side). A way
to trigger the odd IL seen for pr92610.C in a more controlled example
would be nice to have.
[Bug tree-optimization/96020] FRE uses not available def across EH edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96020 --- Comment #1 from Richard Biener --- Created attachment 48819 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48819&action=edit the verifier
[Bug c++/86568] -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568 --- Comment #11 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:8461191b826654a30eaaa57257bcca8e548f11c2 commit r11-1760-g8461191b826654a30eaaa57257bcca8e548f11c2 Author: Martin Sebor Date: Wed Jul 1 08:30:52 2020 -0600 Adjust text of expected warnings changed in PR c++/86568. libstdc++-v3/ChangeLog: * testsuite/21_strings/basic_string_view/cons/char/nonnull.cc: Adjust text of expected warning. * testsuite/21_strings/basic_string_view/cons/wchar_t/nonnull.cc: Same. * testsuite/21_strings/basic_string_view/operations/compare/char/nonnull.cc: Same. * testsuite/21_strings/basic_string_view/operations/find/char/nonnull.cc: Same. * testsuite/21_strings/basic_string_view/operations/rfind/char/nonnull.cc: Same.
[Bug fortran/95446] False positive for optional arguments of elemental procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446 --- Comment #3 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:685d8dafb4a1cb29ee219ad7857614ff66a78022 commit r11-1761-g685d8dafb4a1cb29ee219ad7857614ff66a78022 Author: Mark Eggleston Date: Mon Jun 1 14:56:00 2020 +0100 Fortran : False positive for optional arguments PR95446 Check that there is non-optional argument of the same rank in the list of actual arguments. If there is the warning is not required. 2020-07-01 Steven G. Kargl gcc/fortran/ PR fortran/95446 * resolve.c (resolve_elemental_actual): Add code to check for non-optional argument of the same rank. Revise warning message to refer to the Fortran 2018 standard. 2020-07-01 Mark Eggleston gcc/testsuite/ PR fortran/95446 * gfortran.dg/elemental_optional_args_6.f90: Remove check for warnings that were erroneously output. * gfortran.dg/pr95446.f90: New test.
[Bug middle-end/96007] [9/10/11 Regression] -O2 miscompiles memcmp an object with a string literal containing '\0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96007 Martin Sebor changed: What|Removed |Added Component|tree-optimization |middle-end Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- The patch for pr95189 fixes this as well. Resolving as a duplicate. *** This bug has been marked as a duplicate of bug 95189 ***
[Bug middle-end/95189] [10/11 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 Martin Sebor changed: What|Removed |Added CC||jerryfromearth at gmail dot com --- Comment #9 from Martin Sebor --- *** Bug 96007 has been marked as a duplicate of this bug. ***
[Bug testsuite/96014] [11 regression] g++.dg/analyzer/pr94028.C excess errors starting with r11-1697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96014 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #5 from Martin Sebor --- Reassigning to Jon per comment #4.
[Bug c++/95999] ICE in tree check: expected integer_cst, have var_decl in get_len, at tree.h:5951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95999 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-07-01 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Started with r265055.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #9 from Sergei Trofimovich --- (In reply to Martin Liška from comment #7) > There's ASM diff in between GCC 9 and 10 version: > > diff -u good.s bad.s > --- good.s2020-07-01 15:04:58.315839436 +0200 > +++ bad.s 202 0-07-01 15:04:30.684040487 +0200 Hm, interesting! I think both these files are broken. Let's me try to elaborate b annotating bad-bug.S. All the test does is to print result of comparison of '2' and '1' stored in memory: *lhs = 2; *rhs = 1; int sign = *lhs - *rhs; return sign; But in bad-bug.S we never read from memory! (IPA is disabled to make functions somewhat opaque): """ main: ldi 2,%r28 stw %r2,-20(%r30) ldo 64(%r30),%r30 stw %r28,-52(%r30) ; store '2' in RAM ldo -56(%r30),%r19 ; get RAM address ldi 1,%r28 ldi 0,%r24 ; arg3 = '0' stw %r28,-56(%r30) ; store '1' in RAM copy %r19,%r25 ; arg1 = &2 bl long_richcompare,%r2 ldo -52(%r30),%r26 ; arg0 = &1 (delay slot, executed before branch) ... (all ok so far) long_richcompare: stw %r2,-20(%r30) stwm %r5,64(%r30) copy %r26,%r5; arg0 = &1 stw %r4,-60(%r30) copy %r25,%r4; arg1 = &2 stw %r3,-56(%r30) bl yes,%r2 copy %r24,%r3; arg2 = 0 (delay slot, is it safe in general to comiclr,= 0,%r28,%r0 ; if (!yes()) ... b,n .L22 ; go to actual comparison .L15: ldi 0,%r28 ; fall through to 'return 0;' (not interesting) .L3: .L26: ldw -84(%r30),%r2 ldw -60(%r30),%r4 ldw -56(%r30),%r3 bv %r0(%r2) ldwm -64(%r30),%r5 .L22: bl yes,%r2 nop comib,=,n 0,%r28,.L26 ; if ( .. || !yes()) return 0; (not interesting) ldi 0,%r28 comiclr,<< 5,%r3,%r0 ; check if 'arg3 < 5' to fit into jump table, otherwise skip (nullify) next instruction and run .L3 b,n .L25 ; handle jump table .L12: b .L3; return 0; (not interesting, fall through) ldi 1,%r28 .L25: ldil L'.L8,%r28; ldo R'.L8(%r28),%r28 ; load jump table address ldwx,s %r3(%r28),%r28 ; load target at .L8[arg2 * 4] bv,n %r0(%r28) ; jump on target, should be .L12 .section.rodata .align 4 .L8: .begin_brtab .word .L12 .word .L15 .word .L12 .word .L15 .word .L12 .word .L12 .end_brtab """ Note: during the whole execution at no point in time 'long_richcompare()' tried to dereference arg0 and arg1 inputs (%r4, %r5 registers). For comparison compiling with -O1 keeps the loads around: good-bug.S: """ main: ; same as above stw %r2,-20(%r30) ldo 64(%r30),%r30 ldi 2,%r28 stw %r28,-56(%r30) ldi 1,%r28 ldo -52(%r30),%r19 stw %r28,-52(%r30) ldi 0,%r24 copy %r19,%r25 bl long_richcompare,%r2 ldo -56(%r30),%r26 ... long_richcompare: stw %r2,-20(%r30) stwm %r5,64(%r30) stw %r4,-60(%r30) stw %r3,-56(%r30) copy %r26,%r4 ; arg0 copy %r25,%r3 ; arg1 bl yes,%r2 copy %r24,%r5 ; arg2 or,= %r28,%r0,%r28 ; result = 0 b,n .L11; .L2: ldw -84(%r30),%r2 .L12: ldw -60(%r30),%r4 ldw -56(%r30),%r3 bv %r0(%r2) ; return ldwm -64(%r30),%r5 .L11: bl yes,%r2 nop movb,= %r28,%r28,.L12 ; if(!yes()) return ... ldw -84(%r30),%r2 comb,=,n %r3,%r4,.L9 ; if(arg0 == arg1) (at branch) diff = 0; ldw 0(%r4),%r28 ldw 0(%r3),%r19 sub %r28,%r19,%r28; diff = *arg0 - *arg1 comiclr,<> 0,%r28,%r0 ldi 1,%r28 .L4: comiclr,>>= 5,%r5,%r0 b,n .L6 ldil L'.L7,%r19 ldo R'.L7(%r19),%r19 ldwx,s %r5(%r19),%r19 bv,n %r0(%r19); handle jump table, at .L8 .section.rodata .align 4 .L7: .begin_brtab .word .L8 .word .L10 .word .L6 .word .L10 .word .L6 .word .L6 .end_brtab .text .L9: b .L4 ldi 0,%r28 .L8: comiclr,<> 0,%r28,%r28; if (result == 0) ldi 1,%r28; result = 1; b .L12; return ldw -84(%r30),%r2 .L6: comiclr,<> 0,%r28,%r28 ldi 1,%r28 b .L12 ldw -84(%r30),%r2 .L10: b .L2 ldi 0,%r28 """
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #10 from Sergei Trofimovich --- Created attachment 48820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48820&action=edit good-bug.S
[Bug libquadmath/96016] AArch64: enable libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- You need to use the *l variants of the math functions in c or use tgmath.h which will cause the standard math functions to be type generic.
[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711 --- Comment #7 from Boris Staletic --- I don't know if this is the same problem, since the actual `std::istream_iterator` isn't empty, unlike in the other test cases. If the following is a different problem, sorry up front for the noise. https://godbolt.org/z/XAM9o7 This is the actual thing I've come across during a pull request for NanoRange library. DIfferences from the above test cases: - ICE is there even at `-Og`, as well as `-O0` - The bottom example shows that wrapping the call to `fn()` in `std::move()` avoids the ICE. If this is a separate issue and thus noise, I'll open a separate issue.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #11 from Sergei Trofimovich ---
Looking at -fdump-tree-all:
$gcc/xgcc -B$gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie
-fno-stack-protector -O2 -S bug_test.c -o bad-bug.S -fdump-tree-all
I see that stores are eliminated at 'bad-bug.c.191t.cddce3' stage:
Was (at bad-bug.c.190t.dse3):
"""
__attribute__((noipa, noinline, noclone, no_icf))
long_richcompare (int * self, int * other, int op)
{
int sign;
int result;
int _1;
int _2;
int _5;
int prephitmp_6;
int _13;
int _16;
[local count: 1073741823]:
_1 = yes ();
if (_1 == 0)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 524844999]:
_2 = yes ();
if (_2 == 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 346397698]:
if (self_11(D) == other_12(D))
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 242478389]:
_13 = *self_11(D);
_16 = *other_12(D);
sign_17 = _13 - _16;
if (sign_17 == 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 160035736]:
goto ; [100.00%]
[local count: 103919309]:
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[33.33%], case 3: [33.33%], case 5: [16.67%]>
[local count: 23093180]:
:
goto ; [100.00%]
[local count: 115465900]:
# prephitmp_6 = PHI <0(13), 1(7)>
:
goto ; [100.00%]
[count: 0]:
:
__builtin_unreachable ();
[local count: 727344125]:
[local count: 1073741824]:
# _5 = PHI <0(13), prephitmp_6(9), 0(11), 0(8), 1(7)>
:
return _5;
[local count: 242478389]:
# result_21 = PHI <1(5), sign_17(6)>
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[50.00%], case 3: [50.00%], case 5: [50.00%]>
}
"""
Became (at bad-bug.c.191t.cddce3):
"""
Removing basic block 5
__attribute__((noipa, noinline, noclone, no_icf))
long_richcompare (int * self, int * other, int op)
{
int sign;
int result;
int _1;
int _2;
int _5;
int prephitmp_6;
[local count: 1073741823]:
_1 = yes ();
if (_1 == 0)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 524844999]:
_2 = yes ();
if (_2 == 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 346397698]:
if (self_11(D) == other_12(D))
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 103919309]:
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[33.33%], case 3: [33.33%], case 5: [16.67%]>
[local count: 23093180]:
:
goto ; [100.00%]
[local count: 115465900]:
# prephitmp_6 = PHI <0(11), 1(5)>
:
goto ; [100.00%]
[count: 0]:
:
__builtin_unreachable ();
[local count: 727344125]:
[local count: 1073741824]:
# _5 = PHI <0(11), prephitmp_6(7), 0(9), 0(6), 1(5)>
:
return _5;
[local count: 242478389]:
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[50.00%], case 3: [50.00%], case 5: [50.00%]>
}
"""
Note: the following block disappeared completely:
"""
[local count: 242478389]:
_13 = *self_11(D);
_16 = *other_12(D);
"""
[Bug fortran/52279] Fortran translation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 --- Comment #1 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:0a7183f6d173cbd69025a3deb30d16f91e6392b2 commit r11-1764-g0a7183f6d173cbd69025a3deb30d16f91e6392b2 Author: Mark Eggleston Date: Tue Jun 2 08:38:01 2020 +0100 Fortran : Fortran translation issues PR52279 Mark strings for translation by enclosing in G_() and _(). 2020-06-24 Mark Eggleston gcc/fortran/ PR fortran/52279 * arith.c (reduce_binary_aa): Mark for translation the string parameter to gfc_check_conformance with G_(). * check.c (gfc_invalid_boz): Mark hint for translation using _(). (gfc_check_achar): Mark for translation the message parameter to gfc_invalid_boz using G_(). (gfc_check_char): Mark for translation the message parameter to gfc_invalid_boz using G_(). (gfc_check_complex): Mark for translation the message parameter to gfc_invalid_boz using G_(). (gfc_check_float): Mark for translation the message parameter to gfc_invalid_boz using G_(). (check_rest): Mark for translation the string parameter to gfc_check_conformance with _(). (gfc_check_minloc_maxloc): Mark for translation the string parameter to gfc_check_conformance with _(). (gfc_check_findloc): Mark for translation the string parameter to gfc_check_conformance with _(). (check_reduction): Mark for translation the string parameter to gfc_check_conformance with _(). (gfc_check_pack): Mark for translation the string parameter to gfc_check_conformance with _(). * decl.c (match_old_style_init): Mark for translation the message parameter to gfc_invalid_boz using G_(). * expr.c (gfc_check_assign): Mark for translation the string parameter to gfc_check_conformance with _(). * intrinsic.c (check_specific): Mark for translation the string parameter to gfc_check_conformance with _(). (gfc_check_intrinsic_standard): Mark symstd_msg strings for translation using G_(). No need to mark symstd_msg for translation in call to gfc_warning or when setting symstd. * io.c (check_open_constraints): Mark strings for translation using G_() in all calls to warn_or_error. (match_io_element): Mark for translation the message parameter to gfc_invalid_boz using G_(). * primary.c (match_boz_constant): Mark for translation the message parameter to gfc_invalid_boz using G_(). * resolve.c (resolve_elemental_actual): Mark for translation the string parameter to gfc_check_conformance with _(). (resolve_operator): Mark for translation the string parameter to gfc_check_conformance with _(). Mark translation strings assigned to msg using G_() for use in a call to cfg_warning.
[Bug c++/96021] New: missing -Wnonnull passing nullptr to a nonnull variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96021
Bug ID: 96021
Summary: missing -Wnonnull passing nullptr to a nonnull
variadic lambda
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
G++ issues -Wnonnull when passing nullptr to ordinary variadic functions but
not for the same problem involving variadic lambdas or unspecialized templates.
I believe the problem is due to the -Wnonull warning checking for arguments of
pointer types and the nullptr constant not having such a type.
$ cat q.C && gcc -O2 -S -Wall q.C
__attribute__ ((nonnull)) void f (int, ...);
void ff ()
{
f (1, nullptr);// -Wnonnull (good)
}
template void g (T t)
{
t (1, nullptr);// missing -Wnonnull
}
void gg (void)
{
g ([](int, auto...) __attribute__ ((nonnull)) { });
}
template __attribute__ ((nonnull)) void h (T);
void hh ()
{
h (nullptr); // missing -Wnonnull
}
q.C: In function ‘void ff()’:
q.C:4:16: warning: argument 2 null where non-null expected [-Wnonnull]
4 | f (1, nullptr);// -Wnonnull (good)
|^
q.C:1:32: note: in a call to function ‘void f(int, ...)’ declared ‘nonnull’
1 | __attribute__ ((nonnull)) void f (int, ...);
|^
[Bug c++/96021] missing -Wnonnull passing nullptr to a nonnull variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96021 Martin Sebor changed: What|Removed |Added Version|11.0|8.4.1 Known to fail||10.1.0, 11.0, 8.4.0, 9.3.0 Keywords||diagnostic Blocks||95507 --- Comment #1 from Martin Sebor --- This has never worked as expected. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 [Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #12 from Jeffrey A. Law --- The block in question goes away because it serves no purpose: [local count: 242478389]: _13 = *self_11(D); _16 = *other_12(D); sign_17 = _13 - _16; if (sign_17 == 0) goto ; [34.00%] else goto ; [66.00%] [local count: 160035736]: goto ; [100.00%] Note that bb6 just transfers control to bb13 with no other side effects. As a result bb5 is equivalent to: [local count: 242478389]: _13 = *self_11(D); _16 = *other_12(D); sign_17 = _13 - _16; if (sign_17 == 0) goto ; [34.00%] else goto ; [66.00%] With both arms of the conditional going to the same place and no other uses of sign_17 the whole block just turns into goto ; I see nothing wrong with what was done by DCE. The problem must be earlier in the optimizer pipeline.
[Bug c++/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95984 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- I'm testing a fix.
[Bug tree-optimization/96022] New: ICE during GIMPLE pass: slp in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96022
Bug ID: 96022
Summary: ICE during GIMPLE pass: slp in operator[], at
vec.h:867
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
>$ g++ -c -O3 func.cpp
during GIMPLE pass: slp
func.cpp: In function ‘void test(short int, bool, int)’:
func.cpp:3:6: internal compiler error: in operator[], at vec.h:867
3 | void test(short a, bool, int p8) {
| ^~~~
0x850b10 vec::operator[](unsigned int)
gcc/vec.h:867
0x850b10 vec::operator[](unsigned int)
gcc/vec.h:1433
0x852d71 vec::operator[](unsigned int)
gcc/tree.h:3424
0x852d71 vectorizable_shift
gcc/tree-vect-stmts.c:5492
0x1385aa0 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
gcc/tree-vect-stmts.c:10640
0x13b08e3 vect_schedule_slp_instance
gcc/tree-vect-slp.c:4350
0x13b0904 vect_schedule_slp_instance
gcc/tree-vect-slp.c:4229
0x13b0904 vect_schedule_slp_instance
gcc/tree-vect-slp.c:4229
0x13b72a6 vect_schedule_slp(vec_info*)
gcc/tree-vect-slp.c:4465
0x13b9af0 vect_slp_bb_region
gcc/tree-vect-slp.c:3303
0x13b9af0 vect_slp_bb(basic_block_def*)
gcc/tree-vect-slp.c:3433
0x13bb466 execute
gcc/tree-vectorizer.c:1384
Reproducer:
extern int arr_6[];
extern char arr_7[] __attribute__((aligned));
void test(short a, bool, int p8) {
for (bool b = 0; b < (bool)p8; b = 1)
for (short c = 0; c < 5; c++) {
arr_6[c] = (long)2 << a - 30574;
arr_7[c] = 0;
}
}
GCC version:
11.0.0 20200630 (67ef8cfc1c1d440eafa89a26710bced934a485dc) (GCC)
[Bug c++/77595] concepts: constrained member functions illegally instantiated during explicit class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595 --- Comment #4 from Olivier Kannengieser --- The bug is still there in GCC 10.1, and was the cause of a question of stackoverflow: https://stackoverflow.com/questions/62659801/constrained-member-functions-and-explicit-template-instantiation
[Bug libstdc++/91807] [9/10/11 Regression] std::variant with multiple identical types assignment fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91807 Ville Voutilainen changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|ville.voutilainen at gmail dot com CC||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- Mine.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #13 from Jeffrey A. Law --- Hmm, there's a control dependency though in bb13: [local count: 242478389]: # result_21 = PHI <1(5), sign_17(6)> switch (op_14(D)) [33.33%], case 0: [16.67%], case 1: [50.00%], case 3: [50.00%], case 5: [50.00%]> } So I'd hazard a guess that sign_17 either has the value 1 here or that result_21 is unused, otherwise you're right that cddce shouldn't remove the block.
[Bug fortran/96023] New: Line number for error message differs for x86-64 vs all other architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96023
Bug ID: 96023
Summary: Line number for error message differs for x86-64 vs
all other architectures
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
I don't know how this is possible, but the line number associated with the
error message for gfortran.dg/pr95690.f90 is different for x86-64 than for all
other architectures.
As seen by the lack of failures in x86-64 testsuite reports, the test succeeds
on that target. Manually running the testcase on x86-64 (gcc67) elicits:
pr95690.f90:5:0:
5 | print *, (erfc) ! { dg-error "not a floating constant" }
|
Error: initializer for floating value is not a floating constant
Running the testcase on powerpc64le-linux, powerpc-ibm-aix, s390x-linux,
aarch64-linux, etc. elicits:
pr95690.f90:6:0:
6 |end
|
Error: initializer for floating value is not a floating constant
Same error message associated with a different line.
[Bug fortran/96023] Line number for error message differs for x86-64 vs all other architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96023 David Edelsohn changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-07-01 Status|UNCONFIRMED |NEW --- Comment #1 from David Edelsohn --- Confirmed.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #14 from Sergei Trofimovich --- Created attachment 48821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48821&action=edit bad-bug.c.191t.cddce3 bad-bug.c.191t.cddce3 is the full file generated by -fdump-tree-all-all.
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #5 from Dominique d'Humieres ---
Reduced testcase:
! { dg-do compile }
module target1
contains
subroutine foo (n, o, p, q, r, pp)
integer :: n, o, p, q, r, s, i, j
integer :: a (2:o)
integer, pointer :: pp
!$omp target data device (n + 1) if (n .ne. 6) map (tofrom: n, r)
!$omp target teams device (n + 1) if (n .ne. 6)map (from: n) &
!$omp & map (alloc: a(2:o)) num_teams (n + 4) thread_limit (n * 2) &
!$omp & default(shared) shared(n) private (p) reduction(+:r)
!$omp distribute parallel do simd if(n.ne.6)default(shared)&
!$omp & private (p) firstprivate (q) shared (n) reduction (+: r) &
!$omp & dist_schedule (static, 4) collapse (2) safelen(8) &
!$omp & num_threads (n + 4) proc_bind (spread) lastprivate (s) &
!$omp & schedule (static, 8)
do i = 1, 10
do j = 1, 10
r = r + 1
p = q
a(2+i*10+j) = p + q
s = i * 10 + j
end do
end do
!$omp end target teams
!$omp end target data
end subroutine
end module
[Bug c++/96021] missing -Wnonnull passing nullptr to a nonnull variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96021 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Last reconfirmed||2020-07-01 --- Comment #2 from Martin Sebor --- Fixed in my patch for pr95984.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #15 from Sergei Trofimovich --- Created attachment 48822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48822&action=edit bad-bug.c.190t.dse3 bad-bug.c.190t.dse3 previous tree phase for comparison.
[Bug testsuite/96014] [11 regression] g++.dg/analyzer/pr94028.C excess errors starting with r11-1697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96014 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:039a630d787dc18c76b81f08a322ba1e0d91082d commit r11-1769-g039a630d787dc18c76b81f08a322ba1e0d91082d Author: Jonathan Wakely Date: Tue Jun 30 17:40:08 2020 +0100 analyzer: Fix -Wanalyzer-possible-null-argument warning (PR 96014) gcc/testsuite/ChangeLog: PR testsuite/96014 * g++.dg/analyzer/pr94028.C: Make operator new non-throwing so that the compiler doesn't implicitly mark it as returning non-null.
[Bug fortran/95613] ICE in main_block_label, at tree-cfg.c:1455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95613 --- Comment #3 from G. Steinmetz --- And for the sake of completeness, with another incarnation of goto : $ cat zz2.f90 # etc. program p select case (0) 2 end select stop call s(*2) end
[Bug fortran/96024] New: [9/10/11 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
Bug ID: 96024
Summary: [9/10/11 Regression] ICE in mio_name_expr_t, at
fortran/module.c:2159
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
This invalid code (character char(n) is not a legal len value)
gives an ICE down to r6, seems to be accepted by r5 :
$ cat z1.f90
module m
type t
character(char(1)) :: a
end type
type(t) :: z = t('a')
end
$ gfortran-5 -c z1.f90
$
$ gfortran-11-20200628 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbd215f crash_signal
../../gcc/toplev.c:328
0x696d8c mio_name_expr_t
../../gcc/fortran/module.c:2159
0x696d8c mio_expr
../../gcc/fortran/module.c:3567
0x697543 mio_charlen
../../gcc/fortran/module.c:2629
0x69763c mio_typespec
../../gcc/fortran/module.c:2687
0x696da0 mio_expr
../../gcc/fortran/module.c:3586
0x697543 mio_charlen
../../gcc/fortran/module.c:2629
0x69763c mio_typespec
../../gcc/fortran/module.c:2687
0x6979c5 mio_component
../../gcc/fortran/module.c:2920
0x6989da mio_component_list
../../gcc/fortran/module.c:2957
0x6989da mio_symbol
../../gcc/fortran/module.c:4416
0x698e3d write_symbol
../../gcc/fortran/module.c:5771
0x698fa2 write_symbol0
../../gcc/fortran/module.c:5811
0x698f18 write_symbol0
../../gcc/fortran/module.c:5790
0x698f18 write_symbol0
../../gcc/fortran/module.c:5790
0x69bb04 write_module
../../gcc/fortran/module.c:6153
0x69bb04 dump_module
../../gcc/fortran/module.c:6283
0x69becd gfc_dump_module(char const*, int)
../../gcc/fortran/module.c:6340
0x6b5d26 gfc_parse_file()
../../gcc/fortran/parse.c:6457
0x7016ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to martin.schlipf from comment #4) > Finally, I reproduced it with gfortran 9.3.0 + hdf 1.12.0 and gfortran 10.0 > + hdf 1.10.4. With older versions of gfortran 7.3.0 it does not appear. Workarounds: - compile with -O0, not sure why this makes a difference - or replace in write_real_array_nd: real, intent(in) :: array(*) by real :: array(*) I'd recommend to additionally replace in write_complex_array_3d ierr = write_real_array_4d(locid, dataset_name, ptr) by ierr = write_real_array_4d(locid, dataset_name, & reshape (transfer(array,[1.0]),[2, shape(array)])) The latter is IMO much cleaner Fortran. There might by a bug in gfortran with the way you use c_f_pointer and assumed-size, which generates wrong code for argument packing, or there is a bug elsewhere which may corrupt data subtly.
[Bug fortran/96025] New: [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025 Bug ID: 96025 Summary: [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r6, similar to pr96024 : $ cat z1.f90 program p print *, f() contains character(char(1)) function f() f = 'f' end end $ gfortran-5 -c z1.f90 z1.f90:4:13: character(char(1)) function f() 1 Error: Expression at (1) must be of INTEGER type, found CHARACTER $ gfortran-11-20200628 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbd215f crash_signal ../../gcc/toplev.c:328 0x6592b0 expr_check_typed_help ../../gcc/fortran/expr.c:5437 0x65f90d gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) ../../gcc/fortran/expr.c:5212 0x65f956 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) ../../gcc/fortran/expr.c:5262 0x65fa01 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) ../../gcc/fortran/expr.c:5219 0x65ff5e gfc_expr_check_typed(gfc_expr*, gfc_namespace*, bool) ../../gcc/fortran/expr.c:5475 0x6b13af parse_spec ../../gcc/fortran/parse.c:3829 0x6b3f0c parse_progunit ../../gcc/fortran/parse.c:5852 0x6b42f1 parse_contained ../../gcc/fortran/parse.c:5753 0x6b4196 parse_progunit ../../gcc/fortran/parse.c:5924 0x6b55e9 gfc_parse_file() ../../gcc/fortran/parse.c:6393 0x7016ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/96025] [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Also related : $ cat z2.f90 module m contains character(char(1)) function f() f = 'f' end end program p use m print *, f() end $ gfortran-11-20200628 -c z2.f90 f951: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:5269 0x65fcbf gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) ../../gcc/fortran/expr.c:5269 0x65fa01 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) ../../gcc/fortran/expr.c:5219 0x65ff5e gfc_expr_check_typed(gfc_expr*, gfc_namespace*, bool) ../../gcc/fortran/expr.c:5475 0x6b13af parse_spec ../../gcc/fortran/parse.c:3829 0x6b3f0c parse_progunit ../../gcc/fortran/parse.c:5852 0x6b42f1 parse_contained ../../gcc/fortran/parse.c:5753 0x6b5127 parse_module ../../gcc/fortran/parse.c:6126 0x6b5457 gfc_parse_file() ../../gcc/fortran/parse.c:6429 0x7016ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/95880] [9 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f60918f960594ab6aa6d3082d342385210e8ac90 commit r9-8711-gf60918f960594ab6aa6d3082d342385210e8ac90 Author: Harald Anlauf Date: Sun Jun 28 13:52:09 2020 +0200 PR fortran/95880 - ICE in gfc_add_type, at fortran/symbol.c:2030 The fix for PR39695 did not properly distinguish between procedure names and other symbols names in errors emitted for invalid code. Fix that. gcc/fortran/ PR fortran/95880 * symbol.c (gfc_add_type): If sym->ns->proc_name is set, use it, otherwise fall back to sym->name. (cherry picked from commit f3a8f66a83f8c94f6fbb0233cefba8032f2e4876)
[Bug fortran/71706] [8/9 Regression] [Coarray] ICE on using sync images with integer(kind<>4), with -fcoarray=lib -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71706 --- Comment #17 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0c6cec5ce99a7f532d66373e0ba340c94ef688a6 commit r9-8712-g0c6cec5ce99a7f532d66373e0ba340c94ef688a6 Author: Harald Anlauf Date: Mon Jun 29 15:15:49 2020 +0200 PR fortran/71706 - ICE on using sync images with -fcheck=bounds The run-time checking code did not properly convert the kind of the argument to SYNC IMAGES, leading to an error in verify_gimple. Fix that. gcc/fortran/ PR fortran/71706 * trans-stmt.c (gfc_trans_sync): Do proper kind conversion in bounds-checking code. (cherry picked from commit e6cc67f6616c96f3e18a434e0c74ba2f3818cb6d)
[Bug fortran/95880] [9 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on 10- and 9-branch. Thanks for the report!
[Bug fortran/96024] [9/10/11 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-07-01 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from GCC8 up to master. My instrumented compiler gives ==36165==ERROR: AddressSanitizer: heap-use-after-free on address 0x60401090 at pc 0x0001002a7c06 bp 0x7ffeefbfe5c0 sp 0x7ffeefbfe5b8 READ of size 8 at 0x60401090 thread T0 #0 0x1002a7c05 in mio_expr(gfc_expr**) module.c:3560 #1 0x1002a9986 in mio_charlen(gfc_charlen**) module.c:2629 #2 0x1002aa123 in mio_typespec(gfc_typespec*) module.c:2687 #3 0x1002a7aec in mio_expr(gfc_expr**) module.c:3586 #4 0x1002a9986 in mio_charlen(gfc_charlen**) module.c:2629 #5 0x1002aa123 in mio_typespec(gfc_typespec*) module.c:2687 #6 0x1002ac779 in mio_component(gfc_component*, int) module.c:2920 #7 0x1002acf76 in mio_component_list(gfc_component**, int) module.c:2957 #8 0x1002b221e in mio_symbol(gfc_symbol*) module.c:4416 #9 0x1002b3416 in write_symbol(int, gfc_symbol*) module.c:5771 #10 0x1002bd091 in write_symbol0(gfc_symtree*) module.c:5811 #11 0x1002bcc9f in write_symbol0(gfc_symtree*) module.c:5790 #12 0x1002bcc9f in write_symbol0(gfc_symtree*) module.c:5790 #13 0x1002bd74a in write_module() module.c:6153 #14 0x1002bdc02 in dump_module(char const*, int) module.c:6283 #15 0x1002be369 in gfc_dump_module(char const*, int) module.c:6340 #16 0x100374c6f in gfc_parse_file() parse.c:6457 #17 0x10055a224 in gfc_be_parse_file() f95-lang.c:212 #18 0x106b46254 in compile_file() toplev.c:458 #19 0x106b552e3 in do_compile() toplev.c:2307 #20 0x10a42f19e in toplev::main(int, char**) toplev.c:2446 #21 0x10a933d44 in main main.c:39 #22 0x7fff6bb23cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8) 0x60401090 is located 0 bytes inside of 48-byte region [0x60401090,0x604010c0) freed by thread T0 here: #0 0x15b8378f7 in wrap_free.part.0+0x97 (libasan.6.dylib:x86_64+0x4a8f7) #1 0x10050d6db in gfc_free_charlen(gfc_charlen*, gfc_charlen*) symbol.c:3990 #2 0x10050da95 in gfc_free_namespace(gfc_namespace*) symbol.c:4041 #3 0x1000d5a47 in gfc_match_char_spec(gfc_typespec*) decl.c:3506 #4 0x1000f171d in gfc_match_decl_type_spec(gfc_typespec*, int) decl.c:4166 #5 0x100105f3c in gfc_match_data_decl() decl.c:6126 #6 0x100354b42 in match_word(char const*, match (*)(), locus*) parse.c:65 #7 0x100361a89 in decode_statement() parse.c:376 #8 0x100363fdd in next_free() parse.c:1280 #9 0x10036499a in next_statement() parse.c:1512 #10 0x100369ab2 in parse_derived() parse.c:3343 #11 0x10036b617 in parse_spec(gfc_statement) parse.c:3883 #12 0x100373a04 in parse_module() parse.c:6116 #13 0x100374976 in gfc_parse_file() parse.c:6421 #14 0x10055a224 in gfc_be_parse_file() f95-lang.c:212 #15 0x106b46254 in compile_file() toplev.c:458 #16 0x106b552e3 in do_compile() toplev.c:2307 #17 0x10a42f19e in toplev::main(int, char**) toplev.c:2446 #18 0x10a933d44 in main main.c:39 #19 0x7fff6bb23cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8) previously allocated by thread T0 here: #0 0x15b837fff in wrap_calloc+0xbf (libasan.6.dylib:x86_64+0x4afff) #1 0x109833754 in xcalloc xmalloc.c:162 #2 0x10050b457 in gfc_new_charlen(gfc_namespace*, gfc_charlen*) symbol.c:3954 #3 0x10044a874 in fixup_charlen(gfc_expr*) resolve.c:6078 #4 0x10041538e in gfc_resolve_expr(gfc_expr*) resolve.c:7108 #5 0x1001650df in gfc_reduce_init_expr(gfc_expr*) expr.c:3085 #6 0x1000d59b5 in gfc_match_char_spec(gfc_typespec*) decl.c:3496 #7 0x1000f171d in gfc_match_decl_type_spec(gfc_typespec*, int) decl.c:4166 #8 0x100105f3c in gfc_match_data_decl() decl.c:6126 #9 0x100354b42 in match_word(char const*, match (*)(), locus*) parse.c:65 #10 0x100361a89 in decode_statement() parse.c:376 #11 0x100363fdd in next_free() parse.c:1280 #12 0x10036499a in next_statement() parse.c:1512 #13 0x100369ab2 in parse_derived() parse.c:3343 #14 0x10036b617 in parse_spec(gfc_statement) parse.c:3883 #15 0x100373a04 in parse_module() parse.c:6116 #16 0x100374976 in gfc_parse_file() parse.c:6421 #17 0x10055a224 in gfc_be_parse_file() f95-lang.c:212 #18 0x106b46254 in compile_file() toplev.c:458 #19 0x106b552e3 in do_compile() toplev.c:2307 #20 0x10a42f19e in toplev::main(int, char**) toplev.c:2446 #21 0x10a933d44 in main main.c:39 #22 0x7fff6bb23cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8) ... GCC7 combles the code without error.
[Bug fortran/52622] heap-use-after-free with instrumented compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING Priority|P3 |P4 --- Comment #14 from anlauf at gcc dot gnu.org --- I only see errors on gcc-11 master. Anything left to do? Or close it?
[Bug fortran/96025] [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-07-01 --- Comment #2 from Dominique d'Humieres --- GCC11 and GCC7 give pr96025.f90:4:13: 4 |character(char(1)) function f() | 1 Error: Expression at (1) must be of INTEGER type, found CHARACTER but the instrumented compiler gives ==71986==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400f90 at pc 0x00010015d5e6 bp 0x7ffeefbfe490 sp 0x7ffeefbfe488 READ of size 8 at 0x60400f90 thread T0 #0 0x10015d5e5 in gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) expr.c:5217 #1 0x1001709cb in gfc_expr_check_typed(gfc_expr*, gfc_namespace*, bool) expr.c:5475 #2 0x1003575e0 in check_function_result_typed() parse.c:3720 #3 0x10036b22d in parse_spec(gfc_statement) parse.c:3827 #4 0x100371f06 in parse_progunit(gfc_statement) parse.c:5852 #5 0x100372910 in parse_contained(int) parse.c:5753 #6 0x1003724c5 in parse_progunit(gfc_statement) parse.c:5924 #7 0x10037465f in gfc_parse_file() parse.c:6393 #8 0x10055a224 in gfc_be_parse_file() f95-lang.c:212 #9 0x106b46254 in compile_file() toplev.c:458 #10 0x106b552e3 in do_compile() toplev.c:2307 #11 0x10a42f19e in toplev::main(int, char**) toplev.c:2446 #12 0x10a933d44 in main main.c:39 #13 0x7fff6bb23cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8) 0x60400f90 is located 0 bytes inside of 48-byte region [0x60400f90,0x60400fc0) freed by thread T0 here: #0 0x15b8378f7 in wrap_free.part.0+0x97 (libasan.6.dylib:x86_64+0x4a8f7) #1 0x10050d6db in gfc_free_charlen(gfc_charlen*, gfc_charlen*) symbol.c:3990 #2 0x10050da95 in gfc_free_namespace(gfc_namespace*) symbol.c:4041 #3 0x1000d5a47 in gfc_match_char_spec(gfc_typespec*) decl.c:3506 #4 0x1000f171d in gfc_match_decl_type_spec(gfc_typespec*, int) decl.c:4166 #5 0x1000f59ce in gfc_match_prefix(gfc_typespec*) decl.c:6317 #6 0x100364d2d in match_deferred_characteristics(gfc_typespec*) parse.c:3666 #7 0x10036ba1e in parse_spec(gfc_statement) parse.c:3936 #8 0x100371f06 in parse_progunit(gfc_statement) parse.c:5852 #9 0x100372910 in parse_contained(int) parse.c:5753 #10 0x1003724c5 in parse_progunit(gfc_statement) parse.c:5924 #11 0x10037465f in gfc_parse_file() parse.c:6393 #12 0x10055a224 in gfc_be_parse_file() f95-lang.c:212 #13 0x106b46254 in compile_file() toplev.c:458 #14 0x106b552e3 in do_compile() toplev.c:2307 #15 0x10a42f19e in toplev::main(int, char**) toplev.c:2446 #16 0x10a933d44 in main main.c:39 #17 0x7fff6bb23cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8) previously allocated by thread T0 here: #0 0x15b837fff in wrap_calloc+0xbf (libasan.6.dylib:x86_64+0x4afff) #1 0x109833754 in xcalloc xmalloc.c:162 #2 0x10050b457 in gfc_new_charlen(gfc_namespace*, gfc_charlen*) symbol.c:3954 #3 0x10044a874 in fixup_charlen(gfc_expr*) resolve.c:6078 #4 0x10041538e in gfc_resolve_expr(gfc_expr*) resolve.c:7108 #5 0x1001650df in gfc_reduce_init_expr(gfc_expr*) expr.c:3085 #6 0x1000d59b5 in gfc_match_char_spec(gfc_typespec*) decl.c:3496 #7 0x1000f171d in gfc_match_decl_type_spec(gfc_typespec*, int) decl.c:4166 #8 0x1000f59ce in gfc_match_prefix(gfc_typespec*) decl.c:6317 #9 0x100364d2d in match_deferred_characteristics(gfc_typespec*) parse.c:3666 #10 0x10036ba1e in parse_spec(gfc_statement) parse.c:3936 #11 0x100371f06 in parse_progunit(gfc_statement) parse.c:5852 #12 0x100372910 in parse_contained(int) parse.c:5753 #13 0x1003724c5 in parse_progunit(gfc_statement) parse.c:5924 #14 0x10037465f in gfc_parse_file() parse.c:6393 #15 0x10055a224 in gfc_be_parse_file() f95-lang.c:212 #16 0x106b46254 in compile_file() toplev.c:458 #17 0x106b552e3 in do_compile() toplev.c:2307 #18 0x10a42f19e in toplev::main(int, char**) toplev.c:2446 #19 0x10a933d44 in main main.c:39 #20 0x7fff6bb23cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8) For GCC8 to GCC10 I get a (null):0: confused by earlier errors, bailing out (release builds)/
[Bug fortran/52622] heap-use-after-free with instrumented compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #15 from Dominique d'Humieres --- > I only see errors on gcc-11 master. Anything left to do? Or close it? You need an instrumented compiler to see the ==85033==ERROR: AddressSanitizer: heap-use-after-free on address 0x613aa8da at pc 0x0001003fed9b bp 0x7ffeefbfe920 sp 0x7ffeefbfe918 ... error. With a regular compiler I see erratic errors: in pp_quoted_string, at pretty-print.c:1838
[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921 --- Comment #4 from Rich Felker --- The related issue I meant to link to is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681 which is for x87, but the equivalent happens on m68k due to FLT_EVAL_METHOD being 2 here as well.
[Bug libstdc++/94627] [9/10/11 Regression] std::match_results equality comparisons should not be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94627 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a1a0dc4548979f8a340a7ea71624a52a20e1e0b3 commit r11-1770-ga1a0dc4548979f8a340a7ea71624a52a20e1e0b3 Author: Jonathan Wakely Date: Wed Jul 1 21:01:15 2020 +0100 libstdc++: Remove noexcept from match_results comparisons (PR 94627) These functions can't be noexcept because the iterators stored in the sub_match objects can throw on any operation. libstdc++-v3/ChangeLog: PR libstdc++/94627 * include/bits/regex.h (operator==, operator!=): Remove noexcept equality comparisons for match_results. * testsuite/28_regex/match_results/94627.cc: New test.
[Bug testsuite/96014] [11 regression] g++.dg/analyzer/pr94028.C excess errors starting with r11-1697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96014 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- .
[Bug tree-optimization/94882] Failure to optimize and+or+sub into xor+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94882 --- Comment #2 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:553c6572061f6f9ef92514e8f13de95d509ad614 commit r11-1771-g553c6572061f6f9ef92514e8f13de95d509ad614 Author: Jeff Law Date: Wed Jul 1 14:44:07 2020 -0600 match.pd: (x & y) - (x | y) - 1 -> ~(x ^ y) simplification [PR94882] gcc/ PR tree-optimization/94882 * match.pd (x & y) - (x | y) - 1 -> ~(x ^ y): New simplification. gcc/testsuite/ PR tree-optimization/94882 * gcc.dg/tree-ssa/pr94882.c: New test. * gcc.dg/tree-ssa/pr94882-1.c: New test. * gcc.dg/tree-ssa/pr94882-2.c: New test. * gcc.dg/tree-ssa/pr94882-3.c: New test.
[Bug tree-optimization/94882] Failure to optimize and+or+sub into xor+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94882 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jeffrey A. Law --- This should be fixed on the trunk now.
[Bug fortran/96025] [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/96025] [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
This fixes the ICE. Patch is against svn revision 280156.
e-ts.u.cl is a garbage pointer.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -3447,6 +3447,7 @@ gfc_specification_expr (gfc_expr *e)
{
gfc_error ("Expression at %L must be of INTEGER type, found %s",
&e->where, gfc_basic_typename (e->ts.type));
+ gfc_clear_ts (&e->ts);
return false;
}
