[Bug tree-optimization/86504] vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504 --- Comment #9 from Richard Biener --- (In reply to Joel Hutton from comment #8) > (In reply to Richard Biener from comment #3) > > Hi Richard, > > > So the vectorization issue would be that basic-block vectorization doesn't > > catch this in a very nice way - on x86 we pull out the invariant computation > > and have a vectorized (outer) loop storing to d. > > Just a small clarification, do you mean to say that there is a difference > between the way x86 and aarch64 handle this, as far as I can see they handle > this in the same way. No, I was just mentioning I inspected this on x86 because I do expect the handling to be the same.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #9 from rguenther at suse dot de ---
On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #8 from Xiong Hu XS Luo ---
> (In reply to Thomas Koenig from comment #6)
> > (In reply to Xiong Hu XS Luo from comment #4)
> >
> > > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> > > :(.text+0x114): undefined reference to `_gfortran_st_write'
> > > :(.text+0x12c): undefined reference to
> > > `_gfortran_transfer_character_write'
> >
> > You're not linkging against libgfortran.
> >
> > Either use gfortran as command for compiling or linking, or
> > add the appropriate libraries (-lgfortran -lquadmath) to
> > the linking step.
>
> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
> regression was fixed by Martin's new change.
>
> The c code included math.h actually.
>
> cat atan2bashzowie.c
> #include
> #include
> #include
>
> double __attribute__((noinline)) zowie (double x, double y, double z)
> {
> return atan2 (x * y, z);
> }
>
> double __attribute__((noinline)) rand_finite_double (void)
> {
> union {
> double d;
> unsigned char uc[sizeof(double)];
> } u;
> do {
> for (unsigned i = 0; i < sizeof u.uc; i++) {
> u.uc[i] = (unsigned char) rand();
> }
> } while (!isfinite(u.d));
> return u.d;
> }
>
> int main ()
> {
> double a = rand_finite_double ();
> printf ("%lf\n", zowie (a, 4.5, 2.2));
> return 0;
> }
> cat build.sh
> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
> a.out
> nm a.out | grep atan2
> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8
> -o
> a.out
> nm a.out | grep atan2
> ./build.sh
> 1700 T atan2
> 1700 T _atan2
> 17e0 T atan2
> 17e0 T _atan2
Err, but [_]atan2 are surely not vector variants. Also is massv a static
library here? It looks more like you are not getting the code vectorized
with -flto but without and both variants end up using massv (the -flto
variant using the scalar atan2)?
That said, you have to do more detailed analysis of what actually
happens and what you _want_ to happen. The bugreport summary
doesn't really match what you show.
[Bug tree-optimization/91178] [9/10 Regression] Infinite recursion in split_constant_offset in slp after r260289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Known to work|10.0|
Summary|[9 Regression] Infinite |[9/10 Regression] Infinite
|recursion in|recursion in
|split_constant_offset in|split_constant_offset in
|slp after r260289 |slp after r260289
Known to fail||10.0
--- Comment #9 from Martin Liška ---
(In reply to Vsevolod Livinskiy from comment #8)
> It looks like the fix doesn't handle all of the cases. I still can see
> similar bugs on the trunk.
>
> Reproducer:
> int a[100][70304];
> int b[100];
> void c() {
> for (int d = 2; d < 4; d++)
> for (int e = 2; e <= 50; e++)
> for (int f = 32; f <= 38; f++)
> b[d + f] -= a[e][5];
> }
>
> Error"
> >$ gcc -O3 -march=skylake-avx512 repr.c
> gcc: internal compiler error: Segmentation fault signal terminated program
> cc1
>
> GCC version 10.0.0 (revision: 273743)
Mee too, it's a stack overflow:
$ valgrind --trace-children=yes gcc -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr91178.c -O3
...
==1832== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==1832== Can't extend stack to 0x1ffe800fe8 during signal delivery for thread
1:
==1832== no stack segment
==1832==
==1832== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==1832== Access not within mapped region at address 0x1FFE800FE8
==1832== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==1832==at 0xA87B0C: create (wide-int.h:1193)
==1832==by 0xA87B0C: get_binary_result,
generic_wide_int > (wide-int.h:1207)
==1832==by 0xA87B0C: add,
generic_wide_int > (wide-int.h:2463)
==1832==by 0xA87B0C: wide_int_binop(generic_wide_int&,
tree_code, generic_wide_int const&,
generic_wide_int const&, signop, wi::overflow_type*)
(fold-const.c:1036)
[Bug middle-end/91301] ICE in omp_add_variable on random access iterator distribute parallel for private (iterator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91301 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Wed Jul 31 07:49:56 2019 New Revision: 273922 URL: https://gcc.gnu.org/viewcvs?rev=273922&root=gcc&view=rev Log: PR middle-end/91301 * gimplify.c (gimplify_omp_for): If for class iterator on distribute parallel for there is no data sharing clause on inner_for_stmt, look for private clause on combined parallel too and if found, move it to inner_for_stmt. * testsuite/libgomp.c++/for-27.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/for-27.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/libgomp/ChangeLog
[Bug tree-optimization/91257] [7/8/9/10 Regression] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Jul 31 07:53:11 2019 New Revision: 273923 URL: https://gcc.gnu.org/viewcvs?rev=273923&root=gcc&view=rev Log: 2019-07-31 Richard Biener PR tree-optimization/91257 * tree-vrp.c (union_ranges): Unify equality and less tests by using compare_values. Re-order cheap tests first. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/91178] [9/10 Regression] Infinite recursion in split_constant_offset in slp after r260289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178 --- Comment #10 from Richard Biener --- Yeah, in the end it's still the vectorizers awkward [dead] code generation but for this testcase (for me) it recurses too deeply via the VN triggered by complete unrolling, doing vn_reference_maybe_forwprop_address recursively on the IL. Fortunately this specific case is easily dealt with (compile-time may still be an issue here I guess).
[Bug c++/68957] Wrong overload resolution for unscoped enums with fixed underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68957 Roger Orr changed: What|Removed |Added CC||rogero at howzatt dot demon.co.uk --- Comment #1 from Roger Orr --- This is still open with gcc 9.0...looks like it's stalled?
[Bug other/91255] Can't use define_subst in target that uses set_attr_alternative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91255 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-31 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- This can reproduced by copy-pasting the define_subst example from the documentation https://gcc.gnu.org/onlinedocs/gccint/Define-Subst-Example.html#Define-Subst-Example into and .md file in config/arm. The erroring out happens in has_subst_attribute in gensupport.c. Commenting out the error in case SET_ATTR_ALTERNATIVE and just returning false allows the build to proceed but I suppose we'd want to validate that the set_attr_alternative contents don't contain any subst attributes so that we don't silently reject uses of subst attributes if the backend writer mistakenly expected them to work. Alternatively, there's more error checking in alter_attrs_for_subst_insn that rejects set_attr_alternative but can we rely on that to trigger appropriately?
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 Richard Biener changed: What|Removed |Added Target||arm-none-eabi-gcc CC||hjl.tools at gmail dot com --- Comment #4 from Richard Biener --- You want to look at the output of the linker resolution file (compile with -v -save-temps and look for -fresolution=). The linker probably tells GCC that its "weak" foo() definition is prevailing. This either makes it a non-bug or a binutils bug then.
[Bug tree-optimization/42436] VRP should mark non-trapping integer divisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW CC||amacleod at redhat dot com Blocks||85316 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #2 from Richard Biener --- Andrew is now maintaing VRP. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug tree-optimization/83072] Late VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW CC||amacleod at redhat dot com Blocks||85316 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Richard Biener --- Andrew is now maintaining VRP. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug tree-optimization/91191] vrp and boolean arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW CC||amacleod at redhat dot com Blocks||85316 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Richard Biener --- Andrew is now maintaining VRP. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #5 from Martin Liška --- (In reply to Jan Hubicka from comment #3) > Author: hubicka > Date: Mon Jul 29 08:18:38 2019 > New Revision: 273866 > > URL: https://gcc.gnu.org/viewcvs?rev=273866&root=gcc&view=rev > Log: > > PR lto/91222 > * ipa-devirt.c (warn_types_mismatch): Compare indentifiers > than INDENTIFIER_POINTER. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/ipa-devirt.c Can you Honza please attach a test-case for it to test-suite?
[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Blocks||85316 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug tree-optimization/91257] [7/8/9/10 Regression] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 Richard Biener changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #9 from Richard Biener --- VRP folks want to look at the VRP slowness for this testcase.
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 --- Comment #5 from Martin Liška --- (In reply to Richard Biener from comment #4) > You want to look at the output of the linker resolution file (compile with > -v -save-temps and look for -fresolution=). The linker probably > tells > GCC that its "weak" foo() definition is prevailing. This either makes it > a non-bug or a binutils bug then. $ cat weakdef.res 1 weakdef.o 2 199 b48787268b6fb34e PREEMPTED_REG foo 202 b48787268b6fb34e PREVAILING_DEF main
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #6 from Martin Liška ---
Honza, I can still see cactuBSSN_r failing with:
$ cat 1.i
struct {
} admbaserest_;
$ cat 2.ii
extern "C" {
struct {
} admbaserest_;
}
$ gcc 1.i 2.ii -flto
1.i:2:3: warning: type of ‘admbaserest_’ does not match original declaration
[-Wlto-type-mismatch]
2 | } admbaserest_;
| ^
lto1: internal compiler error: in warn_types_mismatch, at ipa-devirt.c:995
0x62691c warn_types_mismatch(tree_node*, tree_node*, unsigned int, unsigned
int)
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:995
0x7e78cc lto_symtab_merge_decls_2
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:722
0x7e78cc lto_symtab_merge_decls_1
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:861
0x7e78cc lto_symtab_merge_decls()
/home/marxin/Programming/gcc/gcc/lto/lto-symtab.c:887
0x7f3488 read_cgraph_and_symbols(unsigned int, char const**)
/home/marxin/Programming/gcc/gcc/lto/lto-common.c:2839
0x7d9c72 lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:616
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #4 from Bernd Edlinger ---
hmm, funny, I saw this test case failing since february at least:
https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg02686.html
FAIL: gcc.c-torture/execute/20040709-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16
--with-float=hard
I have not looked into it before, but
to me it looks like a reload bug:
str r6, [r5] <= r5 still valid
stm r9, {r0, r1, r2, r3}
umull r5, r3, r7, fp <= r5 clobbered
ldr r2, [r4, #176]
lsr r9, r3, #3
mov r3, r0
eor r3, r3, r2
rsb r9, r9, r9, lsl #4
tst r3, r10
sub r9, fp, r9
bne .L29
ldrhr2, [sp, #176]
ldrhr3, [r4, #176]
eor r2, r2, r3
ubfxr2, r2, #0, #12
cmp r2, #0
bne .L29
cmp r9, r9
bne .L29
mla r6, r8, r6, lr
ldr fp, .L79+36
mla lr, r8, r6, lr
ubfxr6, r6, #16, #11
bfi r3, r6, #0, #12
strhr3, [r4, #176] @ movhi
uxthr8, r3
ldm fp, {r0, r1, r2, r3}
ubfxip, lr, #16, #11
add r7, r6, ip
add ip, sp, #176
bfi r8, r7, #0, #12
str lr, [r5] <= r5 invalid
reload:
(insn 6826 3453 6816 129 (parallel [
(set (reg:SI 3 r3 [4187])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 11
fp [4186]))
(zero_extend:DI (reg:SI 7 r7 [4188])))
(const_int 32 [0x20]
(clobber (reg:SI 5 r5 [5970]))
]) "20040709-1.c":108:291 70 {*umulsi3_highpart_v6}
(nil))
[...]
(insn 3509 3530 3531 132 (set (mem/c:SI (reg/f:SI 5 r5 [5715]) [1
s.5566D.5531+0 S4 A32])
(reg:SI 14 lr [orig:692 D.6083 ] [692])) "20040709-1.c":13:5 654
{*arm_movsi_vfp}
(nil))
[Bug c++/68957] Wrong overload resolution for unscoped enums with fixed underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68957 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-31 Ever confirmed|0 |1
[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 --- Comment #7 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222 > > --- Comment #5 from Martin Liška --- > (In reply to Jan Hubicka from comment #3) > > Author: hubicka > > Date: Mon Jul 29 08:18:38 2019 > > New Revision: 273866 > > > > URL: https://gcc.gnu.org/viewcvs?rev=273866&root=gcc&view=rev > > Log: > > > > PR lto/91222 > > * ipa-devirt.c (warn_types_mismatch): Compare indentifiers > > than INDENTIFIER_POINTER. > > > > Modified: > > trunk/gcc/ChangeLog > > trunk/gcc/ipa-devirt.c > > Can you Honza please attach a test-case for it to test-suite? I still think we should not warn in this case, so plan is to commit it after we discuss the underlying issue why C++ FE declares the types as anonymous. Honza > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/61584] What defines std::underlying_type?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61584 --- Comment #3 from Jonathan Wakely --- (In reply to David Krauss from comment #2) > Currently, enum promotions are incompatible between C and C++ modes. Does that matter? > Furthermore, when C++ requires promotion to signed int but the underlying > type is unsigned int, integer overflow may occur. How? If there are values of the enumeration that would overflow a signed int then it won't be promoted to a signed int. > I think this adds up to a bug and the C++ behavior should get its own bullet > at the end of that manual page. Saying what? The only issue I see here is that EDG chooses int where GCC and Clang choose unsigned int, even in the --g++ mode, but that's not a GCC bug.
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Wed Jul 31 09:22:48 2019 New Revision: 273927 URL: https://gcc.gnu.org/viewcvs?rev=273927&root=gcc&view=rev Log: PR tree-optimization/91201 * config/i386/sse.md (reduc_plus_scal_v16qi): New expander. (REDUC_PLUS_MODE): Add V32QImode for TARGET_AVX and V64QImode for TARGET_AVX512F. (reduc_plus_scal_): Improve formatting by introducing a temporary. * gcc.target/i386/sse2-pr91201.c: New test. * gcc.target/i386/avx2-pr91201.c: New test. * gcc.target/i386/avx512bw-pr91201.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx2-pr91201.c trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr91201.c trunk/gcc/testsuite/gcc.target/i386/sse2-pr91201.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/91257] [7/8/9/10 Regression] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||rguenth at gcc dot gnu.org
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #10 from Richard Biener ---
Otherwise I'm done here. Updated numbers for trunk (release-checking,
non-bootstrapped build with GCC 4.8 host compiler) on the original testcase
time peak rss
-O3 -fwrapv -m32 112s 4.7GB
-O2 -fwrapv -m32 111s 4.7GB
-O2 -fwrapv -m32 -fno-ipa-icf 301s 4.7GB
-O1 -fwrapv -m32 204s 4.5GB
-O1202s 4.5GB
and on the testcase with just gen_opt (the original has gen_opt{,1,2,3,4,5})
-O3 -fwrapv -m3250s 1.7GB
-O2 -fwrapv -m3250s 1.7GB
-O1 34s 1.4GB
so it's clear that ICF simply shrinks the testcase by identifying all
functions as 1:1 identical for the original testcase with -O2+.
Numbers show there's really no IPA component to the testcase then
and looking at a reduced one is fully sufficicent.
Time report for plain -O2:
Time variable usr sys wall
GGC
tree VRP : 5.88 ( 12%) 0.24 ( 25%) 6.10 ( 12%)
598 kB ( 0%)
tree Early VRP : 0.81 ( 2%) 0.00 ( 0%) 0.81 ( 2%)
152 kB ( 0%)
tree copy propagation : 1.42 ( 3%) 0.00 ( 0%) 1.42 ( 3%)
0 kB ( 0%)
tree PTA : 7.77 ( 16%) 0.25 ( 26%) 8.02 ( 16%)
7755 kB ( 1%)
tree SSA rewrite : 1.74 ( 3%) 0.00 ( 0%) 1.75 ( 3%)
629 kB ( 0%)
dominator optimization : 2.29 ( 5%) 0.00 ( 0%) 2.32 ( 5%)
707 kB ( 0%)
tree CCP : 3.57 ( 7%) 0.04 ( 4%) 3.61 ( 7%)
63 kB ( 0%)
tree PRE : 1.69 ( 3%) 0.02 ( 2%) 1.71 ( 3%)
357 kB ( 0%)
tree FRE : 4.15 ( 8%) 0.00 ( 0%) 4.19 ( 8%)
152 kB ( 0%)
tree backward propagate: 1.04 ( 2%) 0.02 ( 2%) 1.06 ( 2%)
0 kB ( 0%)
tree forward propagate : 1.29 ( 3%) 0.00 ( 0%) 1.31 ( 3%)
0 kB ( 0%)
out of ssa : 9.27 ( 19%) 0.00 ( 0%) 9.28 ( 18%)
47 kB ( 0%)
TOTAL : 49.80 0.97 50.79
747309 kB
Time report for plain -O1:
Time variable usr sys wall
GGC
tree copy propagation : 1.40 ( 4%) 0.00 ( 0%) 1.41 ( 4%)
0 kB ( 0%)
tree PTA : 5.78 ( 17%) 0.19 ( 32%) 5.97 ( 18%)
7679 kB ( 1%)
tree SSA rewrite : 1.63 ( 5%) 0.00 ( 0%) 1.63 ( 5%)
629 kB ( 0%)
dominator optimization : 2.29 ( 7%) 0.01 ( 2%) 2.30 ( 7%)
694 kB ( 0%)
tree CCP : 3.53 ( 11%) 0.07 ( 12%) 3.60 ( 11%)
63 kB ( 0%)
tree FRE : 2.74 ( 8%) 0.02 ( 3%) 2.75 ( 8%)
101 kB ( 0%)
tree backward propagate: 1.04 ( 3%) 0.01 ( 2%) 1.05 ( 3%)
0 kB ( 0%)
tree forward propagate : 1.29 ( 4%) 0.00 ( 0%) 1.29 ( 4%)
0 kB ( 0%)
out of ssa : 6.22 ( 19%) 0.00 ( 0%) 6.22 ( 18%)
55 kB ( 0%)
TOTAL : 33.38 0.59 33.98
744713 kB
[Bug ipa/91305] New: ICF compile-time issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91305 Bug ID: 91305 Summary: ICF compile-time issues Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The testcase for PR91257 (https://gcc.gnu.org/bugzilla/attachment.cgi?id=46627) shows 5% compile-time is spent in IPA ICF (it does unify 6 identical large functions down to 1 so overall compile-time wise it's a clear win).
[Bug tree-optimization/90579] [8/9/10 Regression] Huge store forward stall due to vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579 --- Comment #7 from Hongtao.liu --- Transform second loop as diff --git a/loop.c b/loop.c index feea9ea..81a3ea6 100644 --- a/loop.c +++ b/loop.c @@ -9,6 +9,6 @@ loop (int k, double x) for (i=0;i<6;i++) r[i] = x * a[i + k]; for (i=0;i<6;i++) -t+=r[5-i]; +t+=r[i]; using ascending order, align with former loop. return t; } } Can avoid store forward stalls. Before loop transform: loop_avx256: 3710992 loop : 671995 loop_avx128: 650882 After loop transform: loop_avx256: 661386 loop : 652932 loop_avx128: 568710
[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275 --- Comment #1 from Lauri Kasanen --- clang 7.0.0 outputs the expected values, aka the gcc -O0 ones, at all optimization levels. (it calls the builtin __builtin_altivec_crypto_vpmsumd, but no other changes)
[Bug ipa/91305] ICF compile-time issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91305 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/90579] [8/9/10 Regression] Huge store forward stall due to vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579 --- Comment #8 from rguenther at suse dot de --- On Wed, 31 Jul 2019, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579 > > --- Comment #7 from Hongtao.liu --- > Transform second loop as > > diff --git a/loop.c b/loop.c > index feea9ea..81a3ea6 100644 > --- a/loop.c > +++ b/loop.c > @@ -9,6 +9,6 @@ loop (int k, double x) >for (i=0;i<6;i++) > r[i] = x * a[i + k]; >for (i=0;i<6;i++) > -t+=r[5-i]; > +t+=r[i]; using ascending order, align with former loop. >return t; > } > } > > Can avoid store forward stalls. > > Before loop transform: > > loop_avx256: 3710992 > loop : 671995 > loop_avx128: 650882 > > After loop transform: > > loop_avx256: 661386 > loop : 652932 > loop_avx128: 568710 Since the loop is probably unrolled this would be a task for reassociation which should try to make data dependences in a way the scheduler can then order memory accesses in advancing order without increasing register pressure (would also help using pre/post-inc addressing modes on some targets). Currently operand rank for memory accesses is determined by looking at the rank of SSA uses (which there may be none) only.
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 Richard Biener changed: What|Removed |Added Target Milestone|7.5 |--- Summary|[7/8/9/10 Regression] |Compile-time and memory-hog |Compile-time and memory-hog |hog |hog | --- Comment #11 from Richard Biener --- On the reduced testcase GCC 6.5 takes 48s and 1.2GB peak rss for -O3 so it's a regression on the memory-use side but not compile-time. We have ICF since GCC 5 but have since expanded the early pre-IPA pipeline which may explain the regression seen for the larger testcase. With -O3 -fno-ipa-icf compile-time and memory-usage with GCC 6.5 sky-rockets to 275s and 4.3GB so there isn't really much of a regression besides that we added new passes so GCC is expected to get slower. Removing the regression marker.
[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178 --- Comment #12 from Richard Biener --- Author: rguenth Date: Wed Jul 31 09:46:18 2019 New Revision: 273928 URL: https://gcc.gnu.org/viewcvs?rev=273928&root=gcc&view=rev Log: 2019-07-31 Richard Biener PR tree-optimization/91178 * tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Use tail-recursion. * gcc.dg/torture/pr91178-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr91178-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] Infinite |[9 Regression] Infinite |recursion in|recursion in |split_constant_offset in|split_constant_offset in |slp after r260289 |slp after r260289 Known to fail|10.0| --- Comment #11 from Richard Biener --- Fixed again.
[Bug libgcc/91306] New: [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy .init_array entry is too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91306
Bug ID: 91306
Summary: [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy
.init_array entry is too big
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jozefl.gcc at gmail dot com
Target Milestone: ---
In libgcc/crtstuff.c, an alignment of "sizeof (void *)" (i.e. pointer size)
is enforced for the frame_dummy() init_array entry. For msp430-elf in the
large memory model (-mlarge), pointer size is 4 bytes, but the expected
alignment of a pointer is 2 bytes.
So when .init_array is constructed, there could be padding added at the
beginning or between entries, since the structure itself is only aligned to
2 bytes but this entry is aligned to 4 bytes.
The padding causes incorrect execution since the code to run through
.init_array does not expect any gaps between entries since pointers only need
to be 2 byte aligned.
I see this alignment of "sizeof (void *)" was added to fix a mips64 bootstrap
failure in r182066 (https://gcc.gnu.org/ml/gcc-patches/2011-12/msg00393.html),
but this alignment isn't appropriate for msp430.
In crtstuff.c, the type of the init_array entry for frame_dummy is specified
to be "void *", so why must the alignment also be specified?
I don't have access to a mips platform, but shouldn't the entry have the
correct alignment for the type?
Was the addition of the aligned attribute in the 2011 commit a workaround for a
GCC bug? Can it be removed now?
For the following code, GCC generates the the correct alignment without using
the "aligned" attribute on x86, x86_64 and msp430-elf/-mlarge.
static void * entry[]
__attribute__ ((used, section(".init_array"))) = { foo };
x86_64-pc-linux-gnu -m32:
> .section.init_array,"aw"
> .align 4
> .type entry, @object
> .size entry, 4
>entry:
> .long foo
x86_64-pc-linux-gnu -m64:
> .section.init_array,"aw"
> .align 8
> .type entry, @object
> .size entry, 8
>entry:
> .quad foo
msp430-elf -mlarge:
> .section.init_array,"aw"
> .balign 2
> .type entry, @object
> .size entry, 4
>entry:
> .long foo
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #2 from zed.three at gmail dot com --- Forgive me, but what is stupid here? The perceived wisdom is that it is best practice to always use `stat` with `allocate`, and the addition of `errmsg` now gives us something portable to hopefully get a sensible error message. Unfortunately, the error message is not correct here. If you mean trying to allocate a 1D array that is huge(1) -- this is just a large enough value that it's likely to fail due to not enough memory on most machines, as it's about 17GB. A 5D array of real64s of size 64x64x64x64x64 is 8GB, which is definitely not an unrealistic size. That's only 2x10^9 points. I'm certainly not saying this is a show-stopper, but I don't think it's at all stupid to expect useful error messages.
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Eric Müller changed:
What|Removed |Added
CC||mueller at kip dot
uni-heidelberg.
||de
--- Comment #1 from Eric Müller ---
We did a quick search for changes to the "elf_low" insn which is mentioned in
the error message and found commit 55a56a6f323e876a0368f268f2bf85a5739c7498
("PR target/64180", 2014-12-10 by segher).
After reverting this commit (based on "gcc-9_1_0-release") we do not encounter
the problem anymore; the generated assembly looks okay.
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 --- Comment #2 from Philipp Spilger --- Only reverting the "elf_low" insn changes of this commit leads to no encounter of the problem, i.e. the following diff "resolves" the problem on gcc-9_1_0-release. diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index ad80592765d0..f797008eac9b 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -10138,11 +10138,13 @@ "lis %0,%1@ha") (define_insn "elf_low" - [(set (match_operand:SI 0 "gpc_reg_operand" "=r") - (lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b") + [(set (match_operand:SI 0 "gpc_reg_operand" "=r,r") + (lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b,!*r") (match_operand 2 "" "")))] "TARGET_ELF && !TARGET_64BIT && !flag_pic" - "la %0,%2@l(%1)") + "@ +la %0,%2@l(%1) +addic %0,%1,%K2") (define_insn "*pltseq_tocsave_" [(set (match_operand:P 0 "memory_operand" "=m")
[Bug c/91307] New: -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 Bug ID: 91307 Summary: -flto causes binary to vary Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gccbmw at lsmod dot de CC: mliska at suse dot cz Target Milestone: --- When building openSUSE:Factory nvme-cli with -flto=2 it causes a variation in the resulting nvme binary that is not there without -flto /usr/sbin/nvme differs in assembler output @@ -433,7 +433,7 @@ Disassembly of section .text: -_GLOBAL__I_65535_0_cc6lpCUH.o.10070: +_GLOBAL__I_65535_0_cckZcJmg.o.10070: sub$something,%rsp leaoffset(%rip),%rdi# callq strace shows that ["cc", "-D_GNU_SOURCE", "-D__CHECK_ENDIAN__", "-O2", "-Wall", "-D_FORTIFY_SOURCE=2", "-fstack-protector-strong", "-funwind-tables", "-fasynchronous-unwind-tables", "-fstack-clash-protection", "-Werror=return-type", "-flto=2", "-I.", "-std=gnu99", "-I.", "-DLIBUUID", "-DNVME_VERSION=\"1.8.1+git135.9bab71e\"", "nvme.c", "-o", "nvme", "argconfig.o", "suffix.o", "parser.o", "nvme-print.o", "nvme-ioctl.o", "nvme-lightnvm.o", "fabrics.o", "json.o", "nvme-models.o", "plugin.o", "nvme-status.o", "plugins/intel/intel-nvme.o", "plugins/lnvm/lnvm-nvme.o", "plugins/memblaze/memblaze-nvme.o", "plugins/wdc/wdc-nvme.o", "plugins/wdc/wdc-utils.o", "plugins/huawei/huawei-nvme.o", "plugins/netapp/netapp-nvme.o", "plugins/toshiba/toshiba-nvme.o", "plugins/micron/micron-nvme.o", "plugins/seagate/seagate-nvme.o", "plugins/virtium/virtium-nvme.o", "plugins/shannon/shannon-nvme.o", "-luuid"] calls ["/usr/lib64/gcc/x86_64-suse-linux/9/collect2", "-plugin", "/usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so", "-plugin-opt=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper", "-plugin-opt=-fresolution=/tmp/ccQNkgLE.res", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-flto=2", "--build-id", "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-pie", "-o", "nvme", "/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/Scrt1.o", "/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/crti.o", "/usr/lib64/gcc/x86_64-suse-linux/9/crtbeginS.o", "-L/usr/lib64/gcc/x86_64-suse-linux/9", "-L/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64", "-L/lib/../lib64", "-L/usr/lib/../lib64", "-L/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/lib", "-L/usr/lib64/gcc/x86_64-suse-linux/9/../../..", "/tmp/cchuJoLU.o", "argconfig.o", "suffix.o", "parser.o", "nvme-print.o", "nvme-ioctl.o", "nvme-lightnvm.o", "fabrics.o", "json.o", "nvme-models.o", "plugin.o", "nvme-status.o", "plugins/intel/intel-nvme.o", "plugins/lnvm/lnvm-nvme.o", "plugins/memblaze/memblaze-nvme.o", "plugins/wdc/wdc-nvme.o", "plugins/wdc/wdc-utils.o", "plugins/huawei/huawei-nvme.o", "plugins/netapp/netapp-nvme.o", "plugins/toshiba/toshiba-nvme.o", "plugins/micron/micron-nvme.o", "plugins/seagate/seagate-nvme.o", "plugins/virtium/virtium-nvme.o", "plugins/shannon/shannon-nvme.o", "-luuid", "-lgcc", "--push-state", "--as-needed", "-lgcc_s", "--pop-state", "-lc", "-lgcc", "--push-state", "--as-needed", "-lgcc_s", "--pop-state", "/usr/lib64/gcc/x86_64-suse-linux/9/crtendS.o", "/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/crtn.o"] Without -flto the collect2 call also gets the random tmp file passed, but the name is not embedded in the result.
[Bug ipa/69678] Missed function specialization + partial devirtualization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69678 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-31 Ever confirmed|0 |1 --- Comment #1 from Bill Schmidt --- COnfirmed...
[Bug c/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 --- Comment #1 from Simon Schricker --- We also tried building with -pipe, but the observed behavior didn't change.
[Bug tree-optimization/91293] [8/9/10 Regression] Wrong code with -O3 -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91293
--- Comment #4 from Richard Biener ---
Equivalent testcase that doesn't run into the operator swapping and thus works:
long long a;
unsigned b, c;
int d = 62;
void e(long long *f, int p2) { *f = p2; }
int xx = 5, yy = 4;
int main()
{
for (int g = 2; g <= d; g++)
{
c += xx - g;
b += yy + g;
}
e(&a, b);
if (a != 2196)
__builtin_abort ();
return 0;
}
swapping operands confuses reduction code-generation. It would probably
be "easiest" to not swap operands in this case. This results in no longer
vectorizing this in an optimal way but is probably the way to go for release
branches.
[Bug libstdc++/91308] New: [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308
Bug ID: 91308
Summary: [7/8/9/10 Regression] unique_ptr assignment fails with
different deleters
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
As reported at https://gcc.gnu.org/ml/libstdc++/2019-07/msg00088.html this
fails to compile:
#include
struct D1
{
void operator()(int* p) const noexcept { }
};
struct D2 : D1
{
D2& operator=(D1&&) noexcept { return *this; }
};
void
test01()
{
std::unique_ptr d1;
std::unique_ptr d2;
d2 = std::move(d1);
}
void
test02()
{
std::unique_ptr d1;
std::unique_ptr d2;
d2 = std::move(d1);
}
The constraints on the converting assignment operators incorrectly include this
constraint from the converting constructor:
— either D is a reference type and E is the same type as D, or D is not a
reference type and E is implicitly convertible to D.
This used to compile with GCC 5, until r226733.
[Bug libstdc++/91308] [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/91304] maybe_unused attribute ignored on variable declared in if declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-31 Ever confirmed|0 |1
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #10 from wschmidt at linux dot ibm.com ---
On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #9 from rguenther at suse dot de ---
> On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>>
>> --- Comment #8 from Xiong Hu XS Luo ---
>> (In reply to Thomas Koenig from comment #6)
>>> (In reply to Xiong Hu XS Luo from comment #4)
>>>
/tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
:(.text+0x114): undefined reference to `_gfortran_st_write'
:(.text+0x12c): undefined reference to
`_gfortran_transfer_character_write'
>>> You're not linkging against libgfortran.
>>>
>>> Either use gfortran as command for compiling or linking, or
>>> add the appropriate libraries (-lgfortran -lquadmath) to
>>> the linking step.
>> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
>> regression was fixed by Martin's new change.
>>
>> The c code included math.h actually.
>>
>> cat atan2bashzowie.c
>> #include
>> #include
>> #include
>>
>> double __attribute__((noinline)) zowie (double x, double y, double z)
>> {
>> return atan2 (x * y, z);
>> }
>>
>> double __attribute__((noinline)) rand_finite_double (void)
>> {
>> union {
>> double d;
>> unsigned char uc[sizeof(double)];
>> } u;
>> do {
>> for (unsigned i = 0; i < sizeof u.uc; i++) {
>> u.uc[i] = (unsigned char) rand();
>> }
>> } while (!isfinite(u.d));
>> return u.d;
>> }
>>
>> int main ()
>> {
>> double a = rand_finite_double ();
>> printf ("%lf\n", zowie (a, 4.5, 2.2));
>> return 0;
>> }
>> cat build.sh
>> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
>> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
>> a.out
>> nm a.out | grep atan2
>> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
>> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8
>> -o
>> a.out
>> nm a.out | grep atan2
>> ./build.sh
>> 1700 T atan2
>> 1700 T _atan2
>> 17e0 T atan2
>> 17e0 T _atan2
> Err, but [_]atan2 are surely not vector variants. Also is massv a static
> library here? It looks more like you are not getting the code vectorized
> with -flto but without and both variants end up using massv (the -flto
> variant using the scalar atan2)?
>
> That said, you have to do more detailed analysis of what actually
> happens and what you _want_ to happen. The bugreport summary
> doesn't really match what you show.
>
Agree that there's some unnecessary confusion here. I think the
temporary ICE and the build issues obscured the original intent of the bug.
There are two libraries provided with the MASS project. libmass
provides scalar replacements for corresponding libm scalar math
functions. libmassv provides the vectorized versions of those
functions. For this bug we are only concerned about libmass and scalar
math functions.
With the C version of the code, we correctly generate symbols atan2 and
_atan2 that will be satisfied by libmass. With the Fortran version of
the code and without -flto, we again generate symbols atan2f and _atan2f
that will be satisfied by libmass. When we add -flto to the Fortran
version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
disallowing libmass from satisfying them.
We see different behavior in the "visibility" LTO pass between the C and
Fortran versions, which seems to be a clue.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #11 from rguenther at suse dot de ---
On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #10 from wschmidt at linux dot ibm.com ---
> On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >
> > --- Comment #9 from rguenther at suse dot de ---
> > On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> >
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >>
> >> --- Comment #8 from Xiong Hu XS Luo ---
> >> (In reply to Thomas Koenig from comment #6)
> >>> (In reply to Xiong Hu XS Luo from comment #4)
> >>>
> /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> :(.text+0x114): undefined reference to `_gfortran_st_write'
> :(.text+0x12c): undefined reference to
> `_gfortran_transfer_character_write'
> >>> You're not linkging against libgfortran.
> >>>
> >>> Either use gfortran as command for compiling or linking, or
> >>> add the appropriate libraries (-lgfortran -lquadmath) to
> >>> the linking step.
> >> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
> >> regression was fixed by Martin's new change.
> >>
> >> The c code included math.h actually.
> >>
> >> cat atan2bashzowie.c
> >> #include
> >> #include
> >> #include
> >>
> >> double __attribute__((noinline)) zowie (double x, double y, double z)
> >> {
> >> return atan2 (x * y, z);
> >> }
> >>
> >> double __attribute__((noinline)) rand_finite_double (void)
> >> {
> >> union {
> >> double d;
> >> unsigned char uc[sizeof(double)];
> >> } u;
> >> do {
> >> for (unsigned i = 0; i < sizeof u.uc; i++) {
> >> u.uc[i] = (unsigned char) rand();
> >> }
> >> } while (!isfinite(u.d));
> >> return u.d;
> >> }
> >>
> >> int main ()
> >> {
> >> double a = rand_finite_double ();
> >> printf ("%lf\n", zowie (a, 4.5, 2.2));
> >> return 0;
> >> }
> >> cat build.sh
> >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
> >> a.out
> >> nm a.out | grep atan2
> >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv
> >> -lmassvp8 -o
> >> a.out
> >> nm a.out | grep atan2
> >> ./build.sh
> >> 1700 T atan2
> >> 1700 T _atan2
> >> 17e0 T atan2
> >> 17e0 T _atan2
> > Err, but [_]atan2 are surely not vector variants. Also is massv a static
> > library here? It looks more like you are not getting the code vectorized
> > with -flto but without and both variants end up using massv (the -flto
> > variant using the scalar atan2)?
> >
> > That said, you have to do more detailed analysis of what actually
> > happens and what you _want_ to happen. The bugreport summary
> > doesn't really match what you show.
> >
> Agree that there's some unnecessary confusion here. I think the
> temporary ICE and the build issues obscured the original intent of the bug.
>
> There are two libraries provided with the MASS project. libmass
> provides scalar replacements for corresponding libm scalar math
> functions. libmassv provides the vectorized versions of those
> functions. For this bug we are only concerned about libmass and scalar
> math functions.
OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is
linking -lmassv or -lmass_smidp8 then I guess.
> With the C version of the code, we correctly generate symbols atan2 and
> _atan2 that will be satisfied by libmass. With the Fortran version of
> the code and without -flto, we again generate symbols atan2f and _atan2f
> that will be satisfied by libmass. When we add -flto to the Fortran
> version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
> disallowing libmass from satisfying them.
>
> We see different behavior in the "visibility" LTO pass between the C and
> Fortran versions, which seems to be a clue.
I see (on x86) atan2f being used for the fortran testcase since
you are calling atan2 with real() arguments. If you do not use
-fdefault-real-8 you are then comparing apples and oranges.
Maybe MASS doesn't have any float variants?
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #12 from Bill Schmidt --- (In reply to rguent...@suse.de from comment #11) > On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote: > > OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is > linking -lmassv or -lmass_smidp8 then I guess. That's correct. That was just our standard set of flags for linking with MASS/MASSV. It was confusing. > > > With the C version of the code, we correctly generate symbols atan2 and > > _atan2 that will be satisfied by libmass. With the Fortran version of > > the code and without -flto, we again generate symbols atan2f and _atan2f > > that will be satisfied by libmass. When we add -flto to the Fortran > > version of the code, we instead generate symbols for atan2f@@GLIBC_2.17, > > disallowing libmass from satisfying them. > > > > We see different behavior in the "visibility" LTO pass between the C and > > Fortran versions, which seems to be a clue. > > I see (on x86) atan2f being used for the fortran testcase since > you are calling atan2 with real() arguments. If you do not use > -fdefault-real-8 you are then comparing apples and oranges. > > Maybe MASS doesn't have any float variants? No, this used to work. It looks like this started happening a couple of releases ago. We need to drill down on that.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Bill Schmidt changed: What|Removed |Added Known to fail||10.0, 8.3.0, 9.1.0 --- Comment #13 from Bill Schmidt --- It dates back to at least 2018-04-12, when it was reported internally on a SPEC test. I'll mark known-to-fail for GCC 8 going forward.
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Component|c |lto --- Comment #2 from Andrew Pinski --- So it is a global constructor which is picking up the name of the object file.
[Bug target/91303] powerpc-rtems compile error libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91303 --- Comment #2 from Joel Sherrill --- I admit to being completely confused by the multitude of PwerPC variants but if the e500 was deleted, why does libgcc/config.host still include libgcc/config/rs6000/t-savresfgpr for multiple powerpc targets and t-savresfgpr still list files which have e500 in the name?
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Wed Jul 31 13:49:26 2019 New Revision: 273932 URL: https://gcc.gnu.org/viewcvs?rev=273932&root=gcc&view=rev Log: PR tree-optimization/91201 * config/i386/mmx.md (reduc_plus_scal_v8qi): New expander. * gcc.target/i386/sse2-pr91201-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/sse2-pr91201-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #14 from rguenther at suse dot de --- On Wed, 31 Jul 2019, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > Bill Schmidt changed: > >What|Removed |Added > > Known to fail||10.0, 8.3.0, 9.1.0 > > --- Comment #13 from Bill Schmidt --- > It dates back to at least 2018-04-12, when it was reported internally on a > SPEC > test. I'll mark known-to-fail for GCC 8 going forward. Note it can also be a binutils issue, there used to be issues with static library handling and builtins eventually not appearing in the LTO symbol table. Indeed for the fortran example I see 1 t.o 8 334 a12b0c6fed53f76a PREVAILING_DEF_IRONLY square_cube_ 348 a12b0c6fed53f76a PREVAILING_DEF main 363 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write_done 372 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_integer_write 381 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_character_write 383 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write 391 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_options 396 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_args and for a corresponding C testcase 1 t.o 3 198 af89597965b857af PREVAILING_DEF main 211 af89597965b857af PREVAILING_DEF_IRONLY z 213 af89597965b857af PREVAILING_DEF_IRONLY y so no atan2 but an external function foo appears. So the linker probably decides MASS is not needed at all and in the end atan2 comes in via libgfortran linking to libm.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #15 from Richard Biener --- Honza probably knows where we output the LTO symtab and why we do not put undefs for builtins there.
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 CC|mliska at suse dot cz | Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #15)
> Honza probably knows where we output the LTO symtab and why we do not put
> undefs for builtins there.
#include
double y, z;
void foo ();
int main()
{
volatile double x = atan2 (y, z);
foo ();
}
> gcc-8 -c t.c -flto
> gcc-nm t.o
U foo
T main
C y
C z
where's the
U atan2
?
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-07-31
Ever confirmed|0 |1
--- Comment #17 from Richard Biener ---
(In reply to Richard Biener from comment #16)
> (In reply to Richard Biener from comment #15)
> > Honza probably knows where we output the LTO symtab and why we do not put
> > undefs for builtins there.
>
> #include
> double y, z;
> void foo ();
> int main()
> {
> volatile double x = atan2 (y, z);
> foo ();
> }
>
> > gcc-8 -c t.c -flto
> > gcc-nm t.o
> U foo
> T main
> C y
> C z
>
> where's the
>
> U atan2
>
> ?
For
double atan2 (double x, double y) { return x + y; }
it doesn't appear either, this CU has an empty symbol table...
I do remember quite some "funs" with builtin handling though, so the
current handling may be the least bad of all choices...
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307
--- Comment #3 from Bernhard M. Wiedemann ---
It seems to be triggered by nvme-cli/cmd_handler.h
#define PLUGIN(name, cmds) \
static struct plugin plugin = { \
name\
.commands = commands\
}; \
\
static void init(void) __attribute__((constructor));\
static void init(void) \
{ \
register_extension(&plugin);\
}
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #18 from Richard Biener --- So the linker issue would be that during computing of the resolution when the linker decides a whole archive isn't necessary it doesn't re-consider it for the final actual link (which is where GCC exposes the atan2 UNDEF). Instead it happily resolves it to libm which libgfortran drags in? For C and without -lm it doesn't find it and thus _does_ re-consider the previously unused -lmass. I would have expected the link to fail with an unresolved symbol - so the behavior is at least inconsistent.
[Bug libstdc++/91308] [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.5
[Bug target/91303] powerpc-rtems compile error libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91303 --- Comment #3 from Joel Sherrill --- Pursuing the assumption that the e500 files shouldn't be build, I decided to remove them from the t-savresfgpr files. With this patch, powerpc-rtems5 builds again: diff --git a/libgcc/config/rs6000/t-savresfgpr b/libgcc/config/rs6000/t-savresfg index a8455ae..e252cc8 100644 --- a/libgcc/config/rs6000/t-savresfgpr +++ b/libgcc/config/rs6000/t-savresfgpr @@ -7,17 +7,4 @@ LIB2ADD_ST += \ $(srcdir)/config/rs6000/crtresxfpr.S \ $(srcdir)/config/rs6000/crtresxgpr.S \ $(srcdir)/config/rs6000/crtsavevr.S \ - $(srcdir)/config/rs6000/crtrestvr.S \ - $(srcdir)/config/rs6000/e500crtres32gpr.S \ - $(srcdir)/config/rs6000/e500crtres64gpr.S \ - $(srcdir)/config/rs6000/e500crtres64gprctr.S \ - $(srcdir)/config/rs6000/e500crtrest32gpr.S \ - $(srcdir)/config/rs6000/e500crtrest64gpr.S \ - $(srcdir)/config/rs6000/e500crtresx32gpr.S \ - $(srcdir)/config/rs6000/e500crtresx64gpr.S \ - $(srcdir)/config/rs6000/e500crtsav32gpr.S \ - $(srcdir)/config/rs6000/e500crtsav64gpr.S \ - $(srcdir)/config/rs6000/e500crtsav64gprctr.S \ - $(srcdir)/config/rs6000/e500crtsavg32gpr.S \ - $(srcdir)/config/rs6000/e500crtsavg64gpr.S \ - $(srcdir)/config/rs6000/e500crtsavg64gprctr.S + $(srcdir)/config/rs6000/crtrestvr.S
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307
--- Comment #4 from Richard Biener ---
A simple two-file testcase like
static void init(void) __attribute__((constructor));
static void init()
{
static volatile int i = 0;
}
int main() { return 0; }
static void init2(void) __attribute__((constructor));
static void init2()
{
static volatile int i = 0;
}
reproduces this. Having two ctors (in different CUs) is important.
[Bug c++/91309] New: Fails to compile when initializing template argument with immediately-invoked lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91309
Bug ID: 91309
Summary: Fails to compile when initializing template argument
with immediately-invoked lambda
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beachboy44 at me dot com
Target Milestone: ---
https://godbolt.org/z/8O-ItF
The following code fails to compile:
template
struct S {};
template
using T = S< []{ return 0; }() >;
template
using U = T;
using V = U<0>;
error: 'U' does not name a type
However, it compiles when you specify an integer literal as the template
argument to T:
template
using U = T<0>;
[Bug tree-optimization/91293] [8/9 Regression] Wrong code with -O3 -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91293 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] Wrong |[8/9 Regression] Wrong code |code with -O3 -mavx2|with -O3 -mavx2 Known to fail|10.0| --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 --- Comment #5 from Martin Liška --- Confirmed: $ marxin@marxinbox:/tmp> gcc -flto pr91307-*.c -o a.out && objdump -S a.out | grep GLOBAL 00401109 <_GLOBAL__I_65535_0_ccIH3dv1.o.4348>: marxin@marxinbox:/tmp> gcc -flto pr91307-*.c -o a.out && objdump -S a.out | grep GLOBAL 00401109 <_GLOBAL__I_65535_0_ccrEZiHf.o.4348>:
[Bug tree-optimization/91293] [8/9 Regression] Wrong code with -O3 -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91293 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Jul 31 14:15:37 2019 New Revision: 273934 URL: https://gcc.gnu.org/viewcvs?rev=273934&root=gcc&view=rev Log: 2019-07-31 Richard Biener PR tree-optimization/91293 * tree-vect-slp.c (vect_build_slp_tree_2): Do not swap operands of reduction stmts. * gcc.dg/vect/pr91293-1.c: New testcase. * gcc.dg/vect/pr91293-2.c: Likewise. * gcc.dg/vect/pr91293-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/pr91293-1.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-2.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug fortran/91310] New: Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310
Bug ID: 91310
Summary: Read overflow generated by character array assignment
to self
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: foreese at gcc dot gnu.org
Target Milestone: ---
The following simple test cases read_overflow1.for and read_overflow2.for
generate warnings when compiled with -O2 (in gfortran 9.1.0) which allude to
the bug which is a read overflow generated from a character array assignment
within a single variable where the bounds of the LHS and RHS are known.
> $ cat read_overflow1.for
> subroutine s(len)
> implicit none
> character str*512
> integer(4) :: offset
> integer(4), intent(in) :: len
>
> offset = 4
> str(1:) = str(offset:len+3)
> print *, str
> end subroutine
> $ diff read_overflow1.for read_overflow2.for
> 3c3
> < character str*512
> ---
> > character str(512)
> $ gfortran -c -O0 read_overflow1.for # no warning
> $ gfortran -c -O2 read_overflow1.for
> read_overflow1.for:9:0:
>
> 9 | str(1:) = str(offset:len+3)
> |
> Warning: ‘__builtin_memmove’ reading 512 bytes from a region of size 509
> [-Wstringop-overflow=]
> $ gfortran -c -O0 read_overflow2.for # no warning
> $ gfortran -c -O2 read_overflow2.for
> read_overflow2.for:9:0:
>
> 9 | str(1:) = str(offset:len+3)
> |
> Warning: iteration 509 invokes undefined behavior
> [-Waggressive-loop-optimizations]
> read_overflow2.for:9:0: note: within this loop
The issue can be seen in the trees dumped by -fdump-tree-original and
-fdump-tree-optimized, both at -O0 and -O2 for both test cases. The
intermediate code generated is equivalent for both optimization levels. For
read_overflow1.for it boils down to the following:
> _read_length = len - 3;
> if (_read_length < 512) {
> __builtin_memmove(&str, &str+3, _read_length);
> __builtin_memset(&str, ' ', 512 - _read_length);
> } else {
> __builtin_memmove(&str, &str+3, 512);
> }
The trees for read_overflow2.for are similar but are expanded into a loop
equivalent to the following:
> idx = 0;
> while (idx < 512) {
> str[idx][1] = str[idx + 3][1];
> ++idx;
> }
Clearly, code is generated to avoid overflow when _writing_ to str, but there
is no code generated to avoid overflow when _reading_ from str, though both the
source and destination sizes are known. In fact if len is > 509, the last three
characters would result in a read overflow of the str character array and
garbage would be written to the end of the array.
The warnings are only issued in -O2 because the intermediate code is simplified
enough for the overflow to be obvious.
A workaround from the user perspective is to replace the assignment with two
explicitly bounded assignments:
> s(1:len) = s(offset:len+3)
> s(len+1:) = ' '
In this case no overflow can occur from the generated code.
AFAICT the standard does not specify what to do when an assignment occurs among
array sections of differing sizes, so it is up to the compiler to be sensible.
One might argue it is not against the standard to ignore the source size and
always write the destination size -- however, I rather think of it as blatant
negligence on the compiler's part in this case, since the bounds of both are
known and it already tries to avoid overflow of one operation (write) but not
the other (read). If the behavior is intentional and the code _should_ result
in an overflow, then a consistent and obvious warning should be issued for all
optimization levels - but I don't think that it should.
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 --- Comment #1 from Fritz Reese --- Created attachment 46648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46648&action=edit test case 1
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 --- Comment #2 from Fritz Reese --- Created attachment 46649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46649&action=edit test case 2
[Bug c/91192] [9/10 regression] non-deterministic ICE on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91192 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Jul 31 14:32:24 2019 New Revision: 273935 URL: https://gcc.gnu.org/viewcvs?rev=273935&root=gcc&view=rev Log: PR c/91192 * c-parser.c (c_parser_sizeof_expression): Call set_c_expr_source_range even if finish is UNKNOWN_LOCATION, just use start as finish in that case. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c
[Bug c/91192] [9 regression] non-deterministic ICE on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91192 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 regression] |[9 regression] |non-deterministic ICE on|non-deterministic ICE on |invalid |invalid --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/91280] [8/9/10 Regression] ICE in get_constraint_for_component_ref, at tree-ssa-structalias.c:3259 since r260354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91280 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 31 14:38:21 2019 New Revision: 273936 URL: https://gcc.gnu.org/viewcvs?rev=273936&root=gcc&view=rev Log: 2019-07-31 Richard Biener PR tree-optimization/91280 * tree-ssa-structalias.c (get_constraint_for_component_ref): Decompose MEM_REF manually for offset handling. * g++.dg/torture/pr91280.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr91280.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/91280] [8/9 Regression] ICE in get_constraint_for_component_ref, at tree-ssa-structalias.c:3259 since r260354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91280 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |get_constraint_for_componen |get_constraint_for_componen |t_ref, at |t_ref, at |tree-ssa-structalias.c:3259 |tree-ssa-structalias.c:3259 |since r260354 |since r260354 Known to fail|10.0| --- Comment #5 from Richard Biener --- Fixed on trunk.
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310
--- Comment #3 from Fritz Reese ---
Created attachment 46650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46650&action=edit
intermediate code for test case 1
You can see the central condition described in the original report from lines
17-25, and the problematic __builtin_memmove on line 24, which in the optimized
version of the tree causes the warning.
> __builtin_memmove ((void *) &str, (void *) &str[D.3853]{lb: 1 sz: 1}, 512);
[Bug libstdc++/91308] [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Wed Jul 31 14:38:26 2019 New Revision: 273937 URL: https://gcc.gnu.org/viewcvs?rev=273937&root=gcc&view=rev Log: PR libstdc++/91308 fix constraints on unique_ptr assignment PR libstdc++/91308 * include/bits/unique_ptr.h (unique_ptr::__safe_conversion_up): Remove constraints on deleter that should only apply to the constructor. (unique_ptr::__safe_conversion_up): Likewise. (unique_ptr::unique_ptr(unique_ptr&&)): Restore constraints on deleter here. * testsuite/20_util/unique_ptr/assign/91308.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/91308.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/unique_ptr.h
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 --- Comment #6 from Martin Liška --- The name to function is given here: get_file_function_name Breakpoint 1, get_file_function_name (type=0x7fffd670 "I_65535_0") at /home/marxin/Programming/gcc/gcc/tree.c:9809 9809 if (first_global_object_name) (gdb) bt #0 get_file_function_name (type=0x7fffd670 "I_65535_0") at /home/marxin/Programming/gcc/gcc/tree.c:9809 #1 0x00ab7c9b in cgraph_build_static_cdtor_1 (which=, body=0x778958e0, priority=65535, final=, optimization=0x77895880, target=0x7789c558) at /home/marxin/Programming/gcc/gcc/ipa.c:845 #2 0x00ab830b in build_cdtor (ctor_p=true, cdtors=...) at /home/marxin/Programming/gcc/gcc/tree.h:3258 #3 0x00ab877d in build_cdtor_fns (dtors=0x7fffd7d0, ctors=0x7fffd720) at /home/marxin/Programming/gcc/gcc/ipa.c:1064 #4 ipa_cdtor_merge () at /home/marxin/Programming/gcc/gcc/ipa.c:1093 #5 0x00bb9f1a in execute_one_pass (pass=0x2263e60) at /home/marxin/Programming/gcc/gcc/passes.c:2474 #6 0x00bbb927 in execute_ipa_pass_list (pass=0x2263e60) at /home/marxin/Programming/gcc/gcc/passes.c:2914 #7 0x007e1e51 in do_whole_program_analysis () at /home/marxin/Programming/gcc/gcc/context.h:48 #8 lto_main () at /home/marxin/Programming/gcc/gcc/lto/lto.c:628 #9 0x00c8c900 in compile_file () at /home/marxin/Programming/gcc/gcc/toplev.c:456 #10 0x007ba21b in do_compile () at /home/marxin/Programming/gcc/gcc/toplev.c:2190 #11 toplev::main (this=this@entry=0x7fffda6e, argc=, argc@entry=19, argv=, argv@entry=0x7fffdb68) at /home/marxin/Programming/gcc/gcc/toplev.c:2325 #12 0x007bdd2f in main (argc=19, argv=0x7fffdb68) at /home/marxin/Programming/gcc/gcc/main.c:39 So when one uses --save-temps: gcc -flto pr91307-*.c -o a.out --save-temps && objdump -S a.out | grep GLOBAL generating: _GLOBAL__I_65535_0_pr91307_1.o We can probably give a better name in WPA.
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 --- Comment #4 from Fritz Reese --- Created attachment 46651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46651&action=edit intermediate code for test case 2 You can see the central loop described in the original report from lines 18-25. The bounds of the loop are problematic, as iterations 509-511 will overflow the source buffer. The optimized version is able to detect the overflow and issue a warning.
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #7 from Martin Liška ---
Can anything as simple as this resolve it:
diff --git a/gcc/tree.c b/gcc/tree.c
index 8cf75f0..56c0fd450f1 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -9817,12 +9817,17 @@ get_file_function_name (const char *type)
|| (strncmp (type, "sub_", 4) == 0
&& (type[4] == 'I' || type[4] == 'D')))
{
- const char *file = main_input_filename;
- if (! file)
- file = LOCATION_FILE (input_location);
- /* Just use the file's basename, because the full pathname
-might be quite long. */
- p = q = ASTRDUP (lbasename (file));
+ if (flag_wpa)
+ p = q = ASTRDUP ("wpa");
+ else
+ {
+ const char *file = main_input_filename;
+ if (! file)
+ file = LOCATION_FILE (input_location);
+ /* Just use the file's basename, because the full pathname
+might be quite long. */
+ p = q = ASTRDUP (lbasename (file));
+ }
}
else
{
?
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 --- Comment #6 from H.J. Lu --- (In reply to Martin Liška from comment #5) > (In reply to Richard Biener from comment #4) > > You want to look at the output of the linker resolution file (compile with > > -v -save-temps and look for -fresolution=). The linker probably > > tells > > GCC that its "weak" foo() definition is prevailing. This either makes it > > a non-bug or a binutils bug then. > > $ cat weakdef.res > 1 > weakdef.o 2 > 199 b48787268b6fb34e PREEMPTED_REG foo > 202 b48787268b6fb34e PREVAILING_DEF main -O0 and -O1 work. -O2 and above fail. It looks like a GCC bug.
[Bug sanitizer/91311] New: __attribute__ ((aligned (128))) results in stack-use-after-scope and stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311
Bug ID: 91311
Summary: __attribute__ ((aligned (128))) results in
stack-use-after-scope and stack-buffer-overflow
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
This is sporadically (as in, ≈6/10) reproducible on 8.3.0, and not reproducible
on 7.4.0 and 9.1.0. Running the testcase sometimes results in
stack-buffer-overflow sanitizer report, othertimes it's stack-use-after-scope,
and sometimes code passes with no crashes and warnings.
This code is not so small (58 lines) because removing anything from it, or
trying to merge functions, results in getting less crashes or none at all.
Removing the `__attribute__ ((aligned (128)))` results in no crashes from 100
runs; and it's the only odd line of this code, so I suspect this is the
culprit.
Doing `export ASAN_OPTIONS=detect_stack_use_after_return=1` also seems to fix
that.
Despite the testcase being specific to 8.3.0, it seems likely that some similar
problem is present in at least older GCC versions as well. In a project I'm
working on, another developer, with 7.x.x GCC version, also had its share of
odd sanitizer crashes. It's possible, there's the same root reason.
Any suggestions or ideas for how to debug it are welcome.
# Steps to reproduce (in terms of terminal commands)
$ cat asan_testcase.c
#include
#include
#include
struct MyStruct1 {
uint64_t ptr1;
char a;
uint64_t ptr2;
char b;
};
typedef struct {
const uint8_t *raw;
uint64_t err_off;
} MyStruct2 __attribute__ ((aligned (128)));
void test_func() {
struct MyStruct1 test;
char* foo = (char*)&test;
for (size_t i = 0; i < sizeof(struct MyStruct1); ++i)
foo[i] = 0;
printf("test addr: %p", &test);
struct MyStruct1 test2 = {0};
printf("test addr: %p", &test2);
exit(0);
}
void my_bson_destroy(void *foo) {
}
void my_bson_iter_init_find(MyStruct2 *foo, void *bar, const void* p) {
}
void* my_bson_new_from_json(const void* p, int a, int b) {
return 0;
}
static void test_func3() {
void *bson_param = my_bson_new_from_json((const uint8_t*)"{}", -1, 0);
do {
MyStruct2 it;
my_bson_iter_init_find(&it, bson_param, "");
} while(0);
my_bson_destroy(bson_param);
}
static void test_func2(const char* json_params) {
test_func3();
fputs("### rpc_operation_cud_obj called!\n", stderr);
test_func();
}
static void test_func4() { test_func2(0); }
static void* test_func5(void *arg) { test_func4(); abort(); }
int main() {
test_func5(0);
}
$ gcc -fsanitize=address -g3 -O0 -o asan_testcase asan_testcase.c
$ for i in {1..100}; do ./asan_testcase; done
## Expected
Only output from the app, bunch of lines like:
### rpc_operation_cud_obj called!
test addr: 0x7ffe31c987d0test addr: 0x7ffe31c98810%
## Actual
Aborts by address sanitizer: sometimes it's a stack-buffer-overflow:
=
==819==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff118a9010 at pc 0x564fb240f2f6 bp 0x7fff118a8fd0 sp 0x7fff118a8fc0
WRITE of size 1 at 0x7fff118a9010 thread T0
#0 0x564fb240f2f5 in test_func ../iscsi/asan_testcase.c:23
#1 0x564fb240f55c in test_func2 ../iscsi/asan_testcase.c:50
#2 0x564fb240f56d in test_func4 ../iscsi/asan_testcase.c:53
#3 0x564fb240f586 in test_func5 ../iscsi/asan_testcase.c:54
#4 0x564fb240f59e in main ../iscsi/asan_testcase.c:57
#5 0x7f1d87092ce2 in __libc_start_main (/usr/lib/libc.so.6+0x23ce2)
#6 0x564fb240f13d in _start (/tmp/asan_testcase+0x113d)
Address 0x7fff118a9010 is located in stack of thread T0 at offset 32 in
frame
#0 0x564fb240f218 in test_func ../iscsi/asan_testcase.c:19
This frame has 2 object(s):
[32, 64) 'test' <== Memory access at offset 32 is inside this variable
[96, 128) 'test2'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
../iscsi/asan_testcase.c:23 in test_func
Shadow bytes around the buggy address:
0x10006230d1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006230d1c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[Bug middle-end/91131] Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131 --- Comment #13 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939&root=gcc&view=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91126] [7/8/9 regression] Incorrect constant propagation of BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91126 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939&root=gcc&view=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91200] ICE on valid code at -O1: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91200 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939&root=gcc&view=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91145] [9 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.c:1143 with -march=skylake-avx512 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91145 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939&root=gcc&view=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91162] [9 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86 (error: invalid 'PHI' argument)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91162 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939&root=gcc&view=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91162] [7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86 (error: invalid 'PHI' argument)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91162 Richard Biener changed: What|Removed |Added Known to work||9.1.1 Target Milestone|9.2 |7.5 Summary|[9 Regression] ICE: tree|[7/8 Regression] ICE: tree |check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.c:86 (error: |at gimple-expr.c:86 (error: |invalid 'PHI' argument) |invalid 'PHI' argument) --- Comment #7 from Richard Biener --- Latent, so exploring further backport.
[Bug tree-optimization/91145] [9 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.c:1143 with -march=skylake-avx512 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91145 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.1.1 Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug sanitizer/91311] __attribute__ ((aligned (128))) results in stack-use-after-scope and stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311 --- Comment #1 from Konstantin Kharlamov --- Created attachment 46652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46652&action=edit rr record for the testcase, results in stack-use-after-scope I'm also attaching the `rr` record for the testcase resulting in `stack-use-after-scope`. To run it, unpack the directory, and execute: rr replay asan_testcase-0 gdb prompt gonna appear, just type `continue`.
[Bug ada/87100] FAIL: gnat.dg/config_pragma1.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87100 John David Anglin changed: What|Removed |Added Last reconfirmed|2019-03-10 00:00:00 |2019-7-31 CC||helge.deller at sap dot com --- Comment #2 from John David Anglin --- On linux, this message is seen on console: mmap: config_pragma1. (14628): VmData 1018527744 exceed data ulimit 524288000. Update limits or use boot option ignore_rlimit_data. Nominally, ulimit says unlimited. So, I'm not sure where the limit comes from.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #19 from H.J. Lu ---
(In reply to Richard Biener from comment #17)
> (In reply to Richard Biener from comment #16)
> > (In reply to Richard Biener from comment #15)
> > > Honza probably knows where we output the LTO symtab and why we do not put
> > > undefs for builtins there.
> >
> > #include
> > double y, z;
> > void foo ();
> > int main()
> > {
> > volatile double x = atan2 (y, z);
> > foo ();
> > }
> >
> > > gcc-8 -c t.c -flto
> > > gcc-nm t.o
> > U foo
> > T main
> > C y
> > C z
> >
> > where's the
> >
> > U atan2
> >
> > ?
>
> For
>
> double atan2 (double x, double y) { return x + y; }
>
> it doesn't appear either, this CU has an empty symbol table...
>
> I do remember quite some "funs" with builtin handling though, so the
> current handling may be the least bad of all choices...
[hjl@gnu-cfl-1 pr91287]$ cat foo1.c
#include
float
atan2f (float x, float y)
{
abort ();
return x * y;
}
[hjl@gnu-cfl-1 pr91287]$ cat foo.c
float
atan2f (float x, float y)
{
return x * y;
}
[hjl@gnu-cfl-1 pr91287]$ cat bar.c
#include
extern float x, y, z;
void
bar (void)
{
x = atan2f (y, z);
}
[hjl@gnu-cfl-1 pr91287]$ cat main.c
#include
extern void bar (void);
float x, y = 1, z =1;
int
main (void)
{
x = atan2f (y, z);
bar ();
return 0;
}
[hjl@gnu-cfl-1 pr91287]$ make
cc -O3 -c -o foo.o foo.c
ar rc libfoo.a foo.o
cc -O3 -fpic -c -o bar.o bar.c
cc -O3 -fpic -c -o foo1.o foo1.c
ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
ld -shared -o libbar.so bar.o libfoo1.so
cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
./y
./x
make: *** [Makefile:9: all] Aborted
[hjl@gnu-cfl-1 pr91287]$
Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
libfoo.a. atan2f is resolved to definition in libfoo1.so later.
[Bug ada/91169] [10 regression] cd2a31a FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91169 --- Comment #8 from Eric Botcazou --- The patch totally overlooks that the index can wrap around during the traversal of the CONSTRUCTOR: if (index_type) index = wi::ext (index, TYPE_PRECISION (index_type), TYPE_SIGN (index_type)); so the new comparison code cannot reasonably work...
[Bug c/91312] New: -Wconversion warning with += operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312 Bug ID: 91312 Summary: -Wconversion warning with += operator Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kosotiro at yahoo dot gr Target Milestone: ---
[Bug c/91312] -Wconversion warning with += operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312
--- Comment #1 from Kostas Sotiropoulos ---
Hi,
When compiling the following code snippet with gcc 8.3.0
with -Werror=conversion option:
#include
#define MACRO 1
int main(void)
{
unsigned char i;
i += MACRO;
return i;
}
the following warning which is treated as an error is reported:
test.c:3:15: error: conversion from ‘int’ to ‘unsigned char’ may change value
[-Werror=conversion]
#define MACRO 1
^
test.c:9:7: note: in expansion of macro ‘MACRO’
i += MACRO;
^
cc1: some warnings being treated as errors
Should this happen?
From what is described about -Wconversion under the following link:
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc.pdf I am not convinced
that even with casting the right hand of expression this problem should
still appear on this case. Please check this statement:
"Do not warn for explicit casts likeabs ((int) x)andui= (unsigned) -1,
or if the value is not changed by the conversion like inabs(2.0)."
The only solution to this issue is to expand += and then cast to unsigned
char i.e. i = (unsigned char) (i + MACRO)? Should not we be more flexible
on cases of MACRO's even here that integer promotion takes place?
Thank you,
Kostas
[Bug c/91312] -Wconversion warning with += operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Andrew Pinski --- THis is not a bug, In C, "i += MACRO;" is equivant to: i = i + MACRO. And since you are using a type smaller than int, it is prompted to int. NOTE there might be another bug associated with this one.
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #15 from Peter Bergner --- Author: bergner Date: Wed Jul 31 17:18:40 2019 New Revision: 273941 URL: https://gcc.gnu.org/viewcvs?rev=273941&root=gcc&view=rev Log: PR target/91050 * config/rs6000/rs6000.opt (mdejagnu-cpu=): Delete option. * config/rs6000/rs6000.c (rs6000_option_override_internal): Remove use of deleted rs6000_dejagnu_cpu_index variable. * config/rs6000/rs6000.h (DRIVER_SELF_SPECS): Define. (SUBTARGET_DRIVER_SELF_SPECS): Likewise. * config/darwin.h (DRIVER_SELF_SPECS): Rename from this ... (SUBTARGET_DRIVER_SELF_SPECS): ...to this. * config/i386/i386.h (DRIVER_SELF_SPECS): Define. (SUBTARGET_DRIVER_SELF_SPECS): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/config/i386/i386.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.opt
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 Peter Bergner changed: What|Removed |Added Status|NEW |RESOLVED URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-07/msg01899.ht ||ml Resolution|--- |FIXED --- Comment #16 from Peter Bergner --- Fixed.
[Bug lto/91313] New: [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 Bug ID: 91313 Summary: [10 regression] r273908 breaks lto on power 7 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- r273908 | marxin | 2019-07-30 08:45:11 -0500 (Tue, 30 Jul 2019) | 11 lines Deduce automatically number of cores for -flto option. 2019-07-30 Martin Liska * doc/invoke.texi: Document new behavior. * lto-wrapper.c (cpuset_popcount): New function is a copy of libgomp/config/linux/proc.c. (init_num_threads): Likewise. (run_gcc): Automatically detect core count for -flto. (jobserver_active_p): New function. Maybe the automatic core detection isn't working right on power 7? Note that it seems to work OK on power 8 and 9. The errors all look like this: Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ c_lto_2008_0.o c_lto_2008_1.o -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin -o gcc-dg-lto-2008-21.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ c_lto_2008_0.o c_lto_2008_1.o -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin -o gcc-dg-lto-2008-21.exe make[4]: *** write jobserver: Bad file descriptor. Stop. make[4]: *** Waiting for unfinished jobs make[4]: *** write jobserver: Bad file descriptor. Stop. lto-wrapper: fatal error: make returned 2 exit status compilation terminated. collect2: fatal error: lto-wrapper returned 1 exit status compilation terminated. compiler exited with status 1 FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081125 c_lto_20081125_0.o-c_lto_20081125_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090812 c_lto_20090812_0.o-c_lto_20090812_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081125 c_lto_20081125_0.o-c_lto_20081125_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090812 c_lto_20090812_0.o-c_lto_20090812_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20091017-1 c_lto_20091017-1_0.o-c_lto_20091017-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081127 cp_lto_20081127_0.o-cp_lto_20081127_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20091017-1 c_lto_20091017-1_0.o-c_lto_20091017-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090218-1 c_lto_20090218-1_0.o-c_lto_20090218-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090218-1 c_lto_20090218-1_0.o-c_lto_20090218-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc
[Bug rtl-optimization/88233] combine fails to merge insns leaving unneeded reg copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Segher Boessenkool --- Fixed on trunk; no backports planned.
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/90538] [9/10 Regression] Redeclaration error when expanding parameter pack multiple times in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90538 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Jul 31 18:50:00 2019 New Revision: 273944 URL: https://gcc.gnu.org/viewcvs?rev=273944&root=gcc&view=rev Log: PR c++/90538 - multiple expansions of capture packs Previously, with init-capture the type of the closure field was a DECLTYPE_TYPE of the initializer. But since each time we tsubst a lambda we get a different lambda, that meant that if the initializer is a lambda, we'd end up with different closure types in the field and initializer after substitution (PR 87322). We dealt with this by remembering the lambda instantiation within each pack expansion element, using local_specialization_stack to separate the elements. But that broke this testcase, because it lost lambda capture proxies that also use local_specializations. So, this patch removes the local_specializations changes from that patch and fixes 87322 differently, by giving init-capture fields 'auto' type and doing deduction later. There's a bit of a kludge to get the right number of fields by pretending that 'auto...' uses the parameter packs from the initializer, but it does the trick. * cp-tree.h (DECLTYPE_FOR_INIT_CAPTURE): Remove. * lambda.c (add_capture): Copy parameter packs from init. (lambda_capture_field_type): Always use auto for init-capture. * pt.c (uses_parameter_packs): Return tree. (tsubst) [DECLTYPE_TYPE]: Remove init-capture handling. (gen_elem_of_pack_expansion_instantiation): Don't push local_specialization_stack. (prepend_one_capture): New. (tsubst_lambda_expr): Use it. Don't touch local_specializations. (do_auto_deduction): Avoid redundant error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/lambda.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp0x/range-for19.C trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init16.C
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 --- Comment #1 from seurer at gcc dot gnu.org --- I tried this on a different power7 system and it worked OK there. The failing system is running Fedora 28. The one that worked Red hat 6.10. Maybe it is distro related? I will try a couple of others.
[Bug target/89746] powerpc-none-eabi-gcc emits code using stfiwx to misaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Segher Boessenkool --- It's not a regression, so I won't backport it to GCC 8 (and older).
[Bug c++/91264] modifying const-qual object in constexpr context not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91264 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #4 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01914.html
