[Bug middle-end/91739] Missed optimization for arithmetic operations of integers and floating point constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91739 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-12 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Wonder if it's still profitable on 32bits where no native 64bit multiply is available? (but we still have muldi3 expanders so claim support) So unsure if suitable for match.pd or a promotion/demotion pass or whether it's RTL expansion stuff since it heavily depends on target costs. Confirmed.
[Bug c++/91740] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug go/91712] [10 regression] ICE in bind_field_or_method, at go/gofrontend/types.cc:11878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91712 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Ian Lance Taylor --- > Should be fixed by SVN revision 275648 (I forgot to add the PR reference to > the > commit message). It is indeed, thanks.
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #7 from Richard Biener --- flag_unsafe_math_optimizations "trumps" everything to some extent, so yes, I'd say -funsafe-math-optimizations -frounding-math doesn't make much sense.
[Bug tree-optimization/91750] New: Induction vectorization introduces signed overflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91750
Bug ID: 91750
Summary: Induction vectorization introduces signed overflows
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Split out from PR91665.
int val[1024];
void
foo (int n)
{
int i;
for (int j = 0, i = n; j < 1024; ++j, i=(unsigned)i+1)
val[j] = i;
}
generates signed add for the induction vectorization.
[Bug libstdc++/91748] doesn't compile std::for_each_n with random access iterator range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91748 Jonathan Wakely changed: What|Removed |Added Keywords|wrong-code | Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-12 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.3 Ever confirmed|0 |1
[Bug tree-optimization/91665] [8/9 Regression] ICE in build_vector_from_val, at tree.c:1904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91665 Richard Biener changed: What|Removed |Added Known to work||10.0 Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |build_vector_from_val, at |build_vector_from_val, at |tree.c:1904 |tree.c:1904 Known to fail|10.0| --- Comment #8 from Richard Biener --- I've split out the wrong-code issue to PR91750. So this one is fixed on trunk sofar.
[Bug tree-optimization/91750] Induction vectorization introduces signed overflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91750 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-12 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/91686] ICE in gimplify:2554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91686 --- Comment #5 from Paul Thomas --- Author: pault Date: Thu Sep 12 09:05:14 2019 New Revision: 275681 URL: https://gcc.gnu.org/viewcvs?rev=275681&root=gcc&view=rev Log: 2019-09-12 Paul Thomas PR fortran/91686 Backport from mainline * trans-expr.c (gfc_trans_assignment_1): Copy and paste section handling the rse.pre block from mainline. 2019-09-12 Paul Thomas PR fortran/91686 * gfortran.dg/pr91686.f90 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr91686.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #16 from Manfred Schwarb --- Created attachment 46873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46873&action=edit documentation changes for conversion intrinsics
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #17 from Manfred Schwarb --- Here is the documentation fallout I mentioned, previous attachment. And probably a lot of @multitable @columnfractions .20 .20 .20 .25 entries should be widened for the last column, as "Fortran 77 and later" and alike does not fit in a normal 80char Terminal, otherwise.
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 Jakub Jelinek changed: What|Removed |Added Attachment #46871|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 46874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46874&action=edit gcc10-pr91734.patch Updated patch that also handles GE_EXPR comparisons.
[Bug fortran/91686] ICE in gimplify:2554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91686 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed. Thanks for the report. Paul
[Bug tree-optimization/89386] Generation of vectorized MULHRS (Multiply High with Round and Scale) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89386
--- Comment #1 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Sep 12 09:59:58 2019
New Revision: 275682
URL: https://gcc.gnu.org/viewcvs?rev=275682&root=gcc&view=rev
Log:
Vectorise multiply high with scaling operations (PR 89386)
2019-09-12 Yuliang Wang
gcc/
PR tree-optimization/89386
* config/aarch64/aarch64-sve2.md (mull)
(shrnb, shrnt): New SVE2 patterns.
(mulhs3): New pattern for MULHRS.
* config/aarch64/iterators.md (UNSPEC_SMULLB, UNSPEC_SMULLT)
(UNSPEC_UMULLB, UNSPEC_UMULLT, UNSPEC_SHRNB, UNSPEC_SHRNT)
(UNSPEC_RSHRNB, UNSPEC_RSHRNT, UNSPEC_SMULHS, UNSPEC_SMULHRS)
UNSPEC_UMULHS, UNSPEC_UMULHRS): New unspecs.
(MULLBT, SHRNB, SHRNT, MULHRS): New int iterators.
(su, r): Handle the unspecs above.
(bt): New int attribute.
* internal-fn.def (IFN_MULHS, IFN_MULHRS): New internal functions.
* internal-fn.c (first_commutative_argument): Commutativity info for
above.
* optabs.def (smulhs_optab, smulhrs_optab, umulhs_optab)
(umulhrs_optab): New optabs.
* doc/md.texi (smulhs$var{m3}, umulhs$var{m3})
(smulhrs$var{m3}, umulhrs$var{m3}): Documentation for the above.
* tree-vect-patterns.c (vect_recog_mulhs_pattern): New pattern
function.
(vect_vect_recog_func_ptrs): Add it.
* testsuite/gcc.target/aarch64/sve2/mulhrs_1.c: New test.
* testsuite/gcc.dg/vect/vect-mulhrs-1.c: As above.
* testsuite/gcc.dg/vect/vect-mulhrs-2.c: As above.
* testsuite/gcc.dg/vect/vect-mulhrs-3.c: As above.
* testsuite/gcc.dg/vect/vect-mulhrs-4.c: As above.
* doc/sourcebuild.texi (vect_mulhrs_hi): Document new target selector.
* testsuite/lib/target-supports.exp
(check_effective_target_vect_mulhrs_hi): Return true for AArch64
with SVE2.
Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-mulhrs-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-mulhrs-2.c
trunk/gcc/testsuite/gcc.dg/vect/vect-mulhrs-3.c
trunk/gcc/testsuite/gcc.dg/vect/vect-mulhrs-4.c
trunk/gcc/testsuite/gcc.target/aarch64/sve2/mulhrs_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-sve2.md
trunk/gcc/config/aarch64/iterators.md
trunk/gcc/doc/md.texi
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/internal-fn.c
trunk/gcc/internal-fn.def
trunk/gcc/optabs.def
trunk/gcc/testsuite/lib/target-supports.exp
trunk/gcc/tree-vect-patterns.c
[Bug fortran/91717] ICE on concatenating deferred-length character and character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717 --- Comment #3 from Dominique d'Humieres --- The patch at https://gcc.gnu.org/ml/fortran/2019-09/msg00027.html fixes the ICE and the test type core character (len=:), allocatable :: msg end type type(core) :: my_core print *, allocated(my_core%msg) type core character (len=:), allocatable :: msg end type type(core) :: my_core print *, allocated(my_core%msg) my_core%msg = "test" print *, allocated(my_core%msg), len(my_core%msg) my_core%msg = my_core%msg//"message" print *, allocated(my_core%msg) print *, ">", my_core%msg, "<" end gives F T 4 T >testmessage< Is this the expected result?
[Bug debug/91751] New: In backtrace, calls to c++ destructors are shown way afar from the actual place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91751
Bug ID: 91751
Summary: In backtrace, calls to c++ destructors are shown way
afar from the actual place
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
As the title says. I'm not aware of a way to get backtrace with gcc builtins,
so I'm using gdb in testcase, so it's possible that it's a bug in gdb. But to
me a wrong debugging information sounded more likely, so I'm reporting here.
# Steps to reproduce
$ cat test.cpp
#include
struct MyStruct {
void use_the_object() { puts("MyStruct is still in use"); }
~MyStruct() {
puts("MyStruct destructor called");
}
};
int main() {
MyStruct m;
printf("line %i crossed\n", __LINE__);
m.use_the_object();
}
$ g++ test.cpp -o a -g3 -O0
$ ./a
line 12 crossed
MyStruct is still in use
MyStruct destructor called
$ gdb ./a
Reading symbols from ./a...
gdb λ br MyStruct::~MyStruct()
Breakpoint 1 at 0x1214: file test.cpp, line 6.
gdb λ r
Starting program: /tmp/a
line 12 crossed
MyStruct is still in use
Breakpoint 1, MyStruct::~MyStruct (this=0x7fffde27,
__in_chrg=) at test.cpp:6
6 puts("MyStruct destructor called");
gdb λ bt
#0 MyStruct::~MyStruct (this=0x7fffde27, __in_chrg=) at
test.cpp:6
#1 0x51af in main () at test.cpp:11
## Expected
The last line in backtrace has either line test.cpp:13 or 14, because the
destructor could not possibly get called before the last use of the object.
## Actual
Backtrace says it's called at line 11, before the last use of the object.
[Bug debug/91751] In backtrace, calls to c++ destructors are shown way afar from the actual place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91751 --- Comment #1 from Andrew Pinski --- I think there are a few dups of this bug. What happens is the call to deconstructor's line is the same as the object line; rather than the end of the scope.
[Bug debug/91751] In backtrace, calls to c++ destructors are shown way afar from the actual place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91751 --- Comment #2 from Jonathan Wakely --- The advantage of showing the location of the constructor is that you can see which object is being destroyed. If the location was shown as the end of the scope, all local variables would show the same location.
[Bug debug/91751] In backtrace, calls to c++ destructors are shown way afar from the actual place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91751 --- Comment #3 from Konstantin Kharlamov --- (In reply to Jonathan Wakely from comment #2) > The advantage of showing the location of the constructor is that you can see > which object is being destroyed. If the location was shown as the end of the > scope, all local variables would show the same location. Fair enough. But it's confusing too. A function may have multiple places where it "goes out of scope", and if you debug a problem involving an object destructor, it's hard to understand which path got executed. Besides, it's non-intuitive, it looks as if an object was just created, and then immediately destroyed. What you describe, on the other hand, is a natural problem, and should not be worked around by placing line number at place with object creation.
[Bug libstdc++/91748] doesn't compile std::for_each_n with random access iterator range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91748 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Thu Sep 12 10:51:39 2019 New Revision: 275683 URL: https://gcc.gnu.org/viewcvs?rev=275683&root=gcc&view=rev Log: PR libstdc++/91748 fix std::for_each_n for random access iterators PR libstdc++/91748 * include/bits/stl_algo.h (for_each_n): Fix random access iterator case. * testsuite/25_algorithms/for_each/for_each_n.cc: Test with random access iterators. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/testsuite/25_algorithms/for_each/for_each_n.cc
[Bug libstdc++/91748] doesn't compile std::for_each_n with random access iterator range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91748 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed for GCC 9.3 - thanks for reporting this!
[Bug libstdc++/91748] doesn't compile std::for_each_n with random access iterator range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91748 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Thu Sep 12 10:51:58 2019 New Revision: 275684 URL: https://gcc.gnu.org/viewcvs?rev=275684&root=gcc&view=rev Log: PR libstdc++/91748 fix std::for_each_n for random access iterators PR libstdc++/91748 * include/bits/stl_algo.h (for_each_n): Fix random access iterator case. * testsuite/25_algorithms/for_each/for_each_n.cc: Test with random access iterators. Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/include/bits/stl_algo.h branches/gcc-9-branch/libstdc++-v3/testsuite/25_algorithms/for_each/for_each_n.cc
[Bug fortran/91752] New: BOZ constant outside DATA/INT/REAL/DBLE/CMPLX flagged as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752 Bug ID: 91752 Summary: BOZ constant outside DATA/INT/REAL/DBLE/CMPLX flagged as error Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- nagfor and ifort do not flag this as an error, but only warn as an extension: program main implicit none integer :: h h = B"11" end program main This has been introduced into gfortran 10 very recently, but breaks many running codes. Wouldn't you mind turning this into a warning?
[Bug c++/91751] In backtrace, calls to c++ destructors are shown way afar from the actual place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91751 Richard Biener changed: What|Removed |Added Keywords||wrong-debug Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-12 Component|debug |c++ Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- I agree, the consumer should be able to show the point of declaration of the object being destroyed. So IMHO our current location is clearly inferior. C++ FE issue though since that sets the location of the destructor call.
[Bug fortran/91752] BOZ constant outside DATA/INT/REAL/DBLE/CMPLX flagged as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-09-12 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > This has been introduced into gfortran 10 very recently, but breaks many > running codes. Wouldn't you mind turning this into a warning? Use -fallow-invalid-boz. IMO it would be nice to have this option implied by -std=legacy.
[Bug fortran/91752] BOZ constant outside DATA/INT/REAL/DBLE/CMPLX flagged as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752 --- Comment #2 from Jürgen Reuter --- Yes, that would work, but the better workaroud is to replace h = B"11" by h = int (B"11") I convinced the authors of the software we depend upon to do that accordingly.
[Bug tree-optimization/91750] Induction vectorization introduces signed overflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91750 --- Comment #1 from Richard Biener --- Author: rguenth Date: Thu Sep 12 12:48:43 2019 New Revision: 275685 URL: https://gcc.gnu.org/viewcvs?rev=275685&root=gcc&view=rev Log: 2019-09-12 Richard Biener PR tree-optimization/91750 * tree-vect-loop.c (vectorizable_induction): Compute IV increments in the type of the evolution. * gcc.dg/vect/pr91750.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr91750.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/91750] Induction vectorization introduces signed overflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91750 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||10.0 Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed on trunk.
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #8 from Diego Franco ---
So to summarize, these are the main reason why I believe this should be
addressed:
- init brace works for references of any type:
std::vector a {};
std::vector& b {a};
assert(&a == &b); // works
int c {};
int& d {c};
assert(&c == &d); // works
- init brace works for user defined conversion reference when using static
cast:
class A {
operator const std::vector&() const {return a_;}
std::vector a_;
};
A a {};
const auto& b {static_cast&>(a)};
assert(&a == &b); // works
- init brace does not work for user defined conversion reference WITHOUT static
cast:
A a {};
const auto& b {a};
assert(&a == &b); // does not work
I think the above behavior is quite unexpected, and does not follow any logic
of other behaviors in the language. I found this unexpected behavior by running
unit tests. Also, semantic wise is correct to use user-defined-conversion
without static cast (above example).
[Bug middle-end/91753] New: Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
Bug ID: 91753
Summary: Bad register allocation of multi-register types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following example shows that register allocation of types which require
multiple registers is quite non-optimal:
#include
#include
void neon_transform_nada(const uint8x16x4_t table, uint8_t * values, int
volume) {
uint8x16_t x1 = vld1q_u8(values + 0);
uint8x16_t x2 = vld1q_u8(values + 16);
uint8x16_t x3 = vld1q_u8(values + 16*2);
uint8x16_t x4 = vld1q_u8(values + 16*3);
for(int i = 0; i < volume; i++) {
x1 = vqtbx4q_u8(x1, table,x1);
x2 = vqtbx4q_u8(x2, table,x2);
x3 = vqtbx4q_u8(x3, table,x3);
x4 = vqtbx4q_u8(x4, table,x4);
}
vst1q_u8(values + 0,x1);
vst1q_u8(values + 16, x2);
vst1q_u8(values + 16*2, x3);
vst1q_u8(values + 16*3, x4);
}
With -O2/O3:
neon_transform_nada:
cmp w1, 0
ldp q31, q30, [x0]
ldp q29, q28, [x0, 32]
ble .L2
mov v27.16b, v1.16b
mov w2, 0
mov v26.16b, v3.16b
mov v25.16b, v0.16b
mov v24.16b, v2.16b
.p2align 3,,7
.L3:
mov v0.16b, v25.16b
add w2, w2, 1
mov v20.16b, v25.16b
cmp w1, w2
mov v16.16b, v25.16b
mov v4.16b, v25.16b
mov v1.16b, v27.16b
mov v21.16b, v27.16b
mov v17.16b, v27.16b
mov v5.16b, v27.16b
mov v2.16b, v24.16b
mov v22.16b, v24.16b
mov v18.16b, v24.16b
mov v6.16b, v24.16b
mov v3.16b, v26.16b
mov v23.16b, v26.16b
mov v19.16b, v26.16b
mov v7.16b, v26.16b
tbx v31.16b, {v0.16b - v3.16b}, v31.16b
tbx v30.16b, {v20.16b - v23.16b}, v30.16b
tbx v29.16b, {v16.16b - v19.16b}, v29.16b
tbx v28.16b, {v4.16b - v7.16b}, v28.16b
bne .L3
.L2:
stp q31, q30, [x0]
stp q29, q28, [x0, 32]
ret
With -O1 it looks a lot better but there are still 4 redundant moves:
neon_transform_nada:
ldr q19, [x0]
ldr q18, [x0, 16]
ldr q17, [x0, 32]
ldr q16, [x0, 48]
cmp w1, 0
ble .L2
mov w2, 0
.L3:
mov v4.16b, v0.16b
mov v5.16b, v1.16b
mov v6.16b, v2.16b
mov v7.16b, v3.16b
tbx v19.16b, {v4.16b - v7.16b}, v19.16b
tbx v18.16b, {v4.16b - v7.16b}, v18.16b
tbx v17.16b, {v4.16b - v7.16b}, v17.16b
tbx v16.16b, {v4.16b - v7.16b}, v16.16b
add w2, w2, 1
cmp w1, w2
bne .L3
.L2:
str q19, [x0]
str q18, [x0, 16]
str q17, [x0, 32]
str q16, [x0, 48]
ret
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #9 from Diego Franco ---
Correction/editing of last section of former comment:
...
- init brace does not work for user defined conversion reference WITHOUT static
cast:
A a {};
const std::vector& b {a}; // changed from "auto" to "std::vector"
assert(&a == &b); // does not work
...
...
[Bug tree-optimization/65930] Reduction with sign-change not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930 Richard Biener changed: What|Removed |Added Attachment #42730|0 |1 is obsolete|| --- Comment #17 from Richard Biener --- Created attachment 46875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46875&action=edit prototype So here's a patch that can vectorize the testcase. Preparatory cleanup would be moving almost all validity checks from force_simple_reduction to vectorizable_reduction plus storing the core reduction operation (to be used in the epilogue then) from the SCC detection somewhere, not relying on the stmt_info code of the stmt feeding the PHI backedge in vectorizable_reduction (in fact on the forceslp branch that stmt gets vectorized as if being an internal_def, the epilogue is created because its def is "live").
[Bug fortran/91717] ICE on concatenating deferred-length character and character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717 --- Comment #4 from paul.richard.thomas at gmail dot com --- Yes it is - the .false. on entry comes about because the allocatable component must be deallocated on entry to scope. The reallocation on assignment takes care of the rest. Cheers Paul On Thu, 12 Sep 2019 at 11:03, dominiq at lps dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717 > > --- Comment #3 from Dominique d'Humieres --- > The patch at https://gcc.gnu.org/ml/fortran/2019-09/msg00027.html > fixes the ICE and the test > > type core > character (len=:), allocatable :: msg > end type > > type(core) :: my_core > > print *, allocated(my_core%msg) > > type core > character (len=:), allocatable :: msg > end type > > type(core) :: my_core > > print *, allocated(my_core%msg) > > my_core%msg = "test" > print *, allocated(my_core%msg), len(my_core%msg) > > my_core%msg = my_core%msg//"message" > > print *, allocated(my_core%msg) > print *, ">", my_core%msg, "<" > > end > > gives > > F > T 4 > T > >testmessage< > > Is this the expected result? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug c++/91754] New: [c++2a] Defining member function outside of class body fails to compile when containing class is templated on class-type NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91754
Bug ID: 91754
Summary: [c++2a] Defining member function outside of class body
fails to compile when containing class is templated on
class-type NTTP
Product: gcc
Version: 9.2.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/OQHx2M
The following code fails to compile:
struct S {}; // error occurs regardless of whether or not S is empty
template
struct T
{
T(); // declare ctor or mem fn
};
template
inline T::T() {} // define ctor or mem fn
error: invalid use of incomplete type 'struct T<((const S)s)>'
However, defining the ctor or mem fn inside the class body compiles.
[Bug fortran/91752] BOZ constant outside DATA/INT/REAL/DBLE/CMPLX flagged as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from kargl at gcc dot gnu.org --- See the documentation. -fallow-invalid-boz reduces the error to a warning. The warning can only be silenced by -w. This was done with intent.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #18 from Steve Kargl --- On Thu, Sep 12, 2019 at 09:23:54AM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #17 from Manfred Schwarb --- > Here is the documentation fallout I mentioned, previous attachment. > > And probably a lot of > @multitable @columnfractions .20 .20 .20 .25 > entries should be widened for the last column, as "Fortran 77 and later" > and alike does not fit in a normal 80char Terminal, otherwise. > Manfred, If you have commit access, then patches that fix-up the gfortran docs are pre-approve. IMHO, only doc patches that may be controversal or were one might be seeking advice on the English/gammar need a review.
[Bug c++/91755] New: C++ handling of extended characters is not 100% correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91755
Bug ID: 91755
Summary: C++ handling of extended characters is not 100%
correct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lhyatt at gmail dot com
Target Milestone: ---
In C++, technically extended characters (e.g. UTF-8) in the source are supposed
to be converted to UCN escapes during translation phase 1. Thereafter it should
not be detectable whether a UCN or the character itself was used (except in raw
string literals where the conversion is reverted). GCC does not do this
transformation. The distinction is not visible in too many places, but one such
is in preprocessor stringizing.
For instance:
==
#define stringize(x) #x
static_assert(sizeof(stringize("π")) == sizeof(stringize("\U03C0")),
"oops");
==
The above assert should not fire per the letter of the standard, but it does.
I am not sure if it is necessarily desirable to fix this since the existing
behavior seems more intuitive and matches other compilers. But the issue may
become a little more prevalent soon -- as discussed in this thread:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00822.html, a patch will be
applied in the near future that enables extended characters in identifiers too.
Similar to the above case, stringizing such an identifier twice will also make
visible the distinction between UCN- and direct-specified extended characters.
In the new tests being added for this patch
(gcc/testsuite/g++.dg/cpp/ucnid-2-utf8.C and
gcc/testsuite/g++.dg/cpp/ucnid-3-utf8.C), we test that stringizing works for
identifiers containing extended characters, but we test the existing behavior,
which is technically not standard-conforming. So in order to memorialize the
state of things, I am filing this bug report so that I can add a reference to
the situation in the new test cases. If GCC behavior changes in the future,
these new tests will fail and should be adapted to match.
[Bug target/91719] gcc compiles seq_cst store on x86-64 differently from clang/icc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91719 --- Comment #10 from vekumar at gcc dot gnu.org --- xchg is faster than mov+mfence on AMD Zen. We can add m_ZNVER1 | m_ZNVER2 to the tuning.
[Bug tree-optimization/91756] New: [10 regression] g++.dg/lto/alias-3 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756 Bug ID: 91756 Summary: [10 regression] g++.dg/lto/alias-3 FAILs Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20190910 (r275594) and 20190911 (r275651), g++.dg/lto/alias-3 regressed on both Solaris/SPARC and Solaris/x86: +FAIL: g++.dg/lto/alias-3 cp_lto_alias-3_0.o-cp_lto_alias-3_1.o execute -O3 -flto -fno-early-inlining Thread 2 received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xfe289715 in __lwp_sigqueue () from /lib/libc.so.1 (gdb) where #0 0xfe289715 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xfe281fbf in thr_kill () from /lib/libc.so.1 #2 0xfe1c92fa in raise () from /lib/libc.so.1 #3 0xfe19b29e in abort () from /lib/libc.so.1 #4 0x08050e29 in main () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/alias-3_0.C:27 A reghunt identified the following patch as the culprit: 2019-09-11 Richard Biener PR tree-optimization/90387 * vr-values.c (vr_values::extract_range_basic): After inlining simplify non-constant __builtin_constant_p to false. * gcc.dg/Warray-bounds-44.c: New testcase.
[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #14 from Carlos O'Donell --- My preference for would be a distinct *.S file as Florian suggests, it's the most robust solution. The only other alternative I would consider is a new __builtin_get_tls_offset() that does what you want, and then use the builtin. It complicates backporting but solves the problem for all runtimes that want access to a __tls_get_addr() equivalent for the architecture.
[Bug c++/91757] New: Function block scope thread_local variable with unique global symbol linkage is not unique at run-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91757
Bug ID: 91757
Summary: Function block scope thread_local variable with unique
global symbol linkage is not unique at run-time.
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Consider the following application comprised of an executable and a shared
library loaded at run-time.
In the application, static thread_local data member a0 resolves to the same
address from both the executable and shared library, as expected.
Function scope static variable a2 resolves to the same address from both the
executable and shared library, as expected.
Whereas function block scope thread_local variable a1 incorrectly resolves to
different addresses, whereas it must resolve to the same address.
$ cat shared.h
#pragma once
namespace shared {
template
struct A {
static thread_local unsigned a0;
static unsigned* f1() {
thread_local unsigned a1 = 0;
return &a1;
}
static unsigned* f2() {
static unsigned a2 = 0;
return &a2;
}
};
template
thread_local unsigned A::a0 = 0;
unsigned* f0();
unsigned* f1();
unsigned* f2();
} // namespace shared
$ cat shared.cc
#include "shared.h"
unsigned* shared::f0() {
return &A::a0;
}
unsigned* shared::f1() {
return A::f1();
}
unsigned* shared::f2() {
return A::f2();
}
$ cat test.cc
#include "shared.h"
#include
#include
int main() {
using namespace shared;
std::printf("main a0: %p\n", &A::a0);
std::printf("main a1: %p\n", A::f1());
std::printf("main a2: %p\n", A::f2());
void* so = ::dlopen("./libshared.so", RTLD_NOW | RTLD_GLOBAL);
auto pf0 = reinterpret_cast(::dlsym(so, "_ZN6shared2f0Ev"));
auto pf1 = reinterpret_cast(::dlsym(so, "_ZN6shared2f1Ev"));
auto pf2 = reinterpret_cast(::dlsym(so, "_ZN6shared2f2Ev"));
std::printf("shared a0: %p\n", pf0());
std::printf("shared a1: %p\n", pf1());
std::printf("shared a2: %p\n", pf2());
}
$ g++ -c -o test.o -pthread -std=gnu++1z -march=native -W{all,extra,error} -g
-O2 test.cc
$ g++ -c -o shared.o -pthread -std=gnu++1z -march=native -W{all,extra,error} -g
-O2 -fPIC shared.cc
$ g++ -o test -rdynamic -pthread -g test.o -ldl
$ g++ -o libshared.so -shared -pthread -g shared.o
$ nm -C --extern-only --dynamic --defined-only test
00600e90 B __bss_start
00600e80 D __data_start
00600e80 W data_start
00600e90 D _edata
00600e98 B _end
00400a7c T _fini
004007a0 T _init
00400a88 R _IO_stdin_used
004009e0 T __libc_csu_fini
004009f0 T __libc_csu_init
00400800 T main
004008c4 T _start
0004 u shared::A::a0 <--- Unique global object, as
expected.
u shared::A::f1()::a1 <--- Unique global object, as
expected.
00600e94 u shared::A::f2()::a2 <--- Unique global object, as
expected.
$ nm -C --extern-only --dynamic --defined-only libshared.so
00200c78 B __bss_start
00200c78 D _edata
00200c80 B _end
0908 T _fini
0758 T _init
0004 u shared::A::a0 <--- Unique global object, as
expected.
08c0 T shared::f0()
08e0 T shared::f1()
0900 T shared::f2()
u shared::A::f1()::a1 <--- Unique global object, as
expected.
00200c7c u shared::A::f2()::a2 <--- Unique global object, as
expected.
$ ./test
main a0: 0x7fcc4c42171c
main a1: 0x7fcc4c421718
main a2: 0x600e94
shared a0: 0x7fcc4c42171c
shared a1: 0x1b9b330 < wrong address, must resolve to 0x7fcc4c421718.
shared a2: 0x600e94
[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400 Jonathan Wakely changed: What|Removed |Added CC||maxim.yegorushkin at gmail dot com --- Comment #15 from Jonathan Wakely --- *** Bug 91757 has been marked as a duplicate of this bug. ***
[Bug c++/91757] Function block scope thread_local variable with unique global symbol linkage is not unique at run-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91757 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED Known to work||10.0, 8.3.1, 9.1.0 Resolution|--- |DUPLICATE Known to fail||7.4.1, 8.3.0 --- Comment #1 from Jonathan Wakely --- Hi Max! GCC 6.3 is no longer supported, but later releases do have the same bug. The bug is fixed in GCC 9.1, and has been fixed on gcc-8-branch some time after the 8.3 release (so will be fixed for 8.4). I think it's a dup of Bug 90562, which is a dup of Bug 85400. *** This bug has been marked as a duplicate of bug 85400 ***
[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400 --- Comment #16 from Jonathan Wakely --- Is this worth backporting to gcc-7-branch for the final 7.x release?
[Bug c++/91747] Using a type alias leads to wrong static values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91747 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-12 Ever confirmed|0 |1
[Bug tree-optimization/91758] New: Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758 Bug ID: 91758 Summary: Clang fails to pass validation after r261089 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: lukebenes at hotmail dot com Target Milestone: --- With gcc 9 or newer clang will build but fail up to 150 validation tests. The failures first started after: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261089 gimple-ssa-store-merging.c: Include gimple-fold.h. While subsequent gcc tweaks resulted in different tests failing, this commit appears to be the genesis of all of the failures. Steps to Reproduce: 1. git clone https://github.com/llvm/llvm-project.git 2. cd llvm-project 3. mkdir build && cd build 4. CC=gcc CXX=g++ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm 5. make check-all -j4 Expected Results: All tests pass Actual Results: 4-150 tests will fails such as Clang :: CodeGen/arm-fp16-arguments.c Clang :: CodeGen/lanai-regparm.c Clang :: CodeGen/ppc64-complex-parms.c Clang :: CodeGen/ppc64-complex-return.c Clang :: CodeGen/ppc64-vector.c
[Bug tree-optimization/91758] Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-09-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > The failures first started after: > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261089 > gimple-ssa-store-merging.c: Include gimple-fold.h. > > While subsequent gcc tweaks resulted in different tests failing, this commit > appears to be the genesis of all of the failures. > > Steps to Reproduce: > 1. git clone https://github.com/llvm/llvm-project.git > 2. cd llvm-project > 3. mkdir build && cd build > 4. CC=gcc CXX=g++ cmake -DLLVM_ENABLE_PROJECTS=clang > -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm > 5. make check-all -j4 Thanks for reporting the problem, but we need more information and a reproducer, see the instructions at https://gcc.gnu.org/bugs/
[Bug c++/91759] New: g++ accepts ill-formed deduction guides in wrong scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91759
Bug ID: 91759
Summary: g++ accepts ill-formed deduction guides in wrong scope
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
namespace N {
template
struct X{ X(int); };
}
using N::X;
X(int) -> X;
This is supposed to not compile due to
http://eel.is/c++draft/temp.deduct.guide#3.sentence-4: A deduction-guide shall
be declared in the same scope as the corresponding class template and, for a
member class template, with the same access.
clang, icc, and msvc all correctly consider this to be ill-formed:
https://godbolt.org/z/UH3Y8W.
[Bug tree-optimization/89386] Generation of vectorized MULHRS (Multiply High with Round and Scale) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89386 --- Comment #2 from uros at gcc dot gnu.org --- Author: uros Date: Thu Sep 12 19:18:25 2019 New Revision: 275689 URL: https://gcc.gnu.org/viewcvs?rev=275689&root=gcc&view=rev Log: PR tree-optimization/89386 * config/i386/sse.md (smulhrs3): New expander. (smulhrsv4hi3): Ditto. testsuite/ChangeLog: PR tree-optimization/89386 * gcc.target/i386/pr89386.c: New test. * gcc.target/i386/pr89386-1.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/pr89386-1.c trunk/gcc/testsuite/gcc.target/i386/pr89386.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug c++/91760] New: Trailing return type breaks final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91760
Bug ID: 91760
Summary: Trailing return type breaks final specifier
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john.boyer at tutanota dot com
Target Milestone: ---
The following code:
struct final;
struct test
{
virtual auto foo() -> int final;
};
Generates this error:
error: two or more data types in declaration of 'type name'
Example: https://godbolt.org/z/4GSoW_
The same code works fine on clang (https://godbolt.org/z/4d3J85), MSVC
(https://godbolt.org/z/BYq2yW) and ICC (https://godbolt.org/z/_V9Qvd).
Since final and override are "identifiers with special meaning", this code
should compile as there is no ambiguity on whether or not "final" can be an
identifier in this context.
If the trailing return type is changed to a normal return type, this of course
will compile as expected (https://godbolt.org/z/ReWHag):
struct final;
struct test
{
virtual int foo() final;
};
[Bug middle-end/91753] Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization, ra Target||aarch64-linux-gnu --- Comment #1 from Andrew Pinski --- lower-subreg should have be able to help here. I wonder why it did not ...
[Bug libstdc++/88339] Implement P0515R3, C++20 three-way comparison operator support .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88339 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-12 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/88339] Implement P0515R3, C++20 three-way comparison operator support .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88339 --- Comment #1 from Jonathan Wakely --- Created attachment 46876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46876&action=edit Partial implementation of This patch adds an incomplete and untested header. This depends on my implementation of the header, which I'll be committing to the concepts-cxx2a branch soon.
[Bug fortran/91557] [7/8/9/10 Regression] Bogus warning about unused dummy argument _formal_*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-12 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/91716] [9/10 Regression] ICE in output_constant, at varasm.c:5026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91716 --- Comment #2 from Bernd Edlinger --- Created attachment 46877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46877&action=edit untested patch
[Bug c++/91761] New: Overloaded new operator compiled with -O3 option distorts original C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91761 Bug ID: 91761 Summary: Overloaded new operator compiled with -O3 option distorts original C++ code Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redsoftk at yahoo dot com Target Milestone: --- Created attachment 46878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46878&action=edit simple sample to reproduce the problem Starting from gcc ver 7.4 (versions <=5.4 worked correctly) the code implementing overloading new operators produces strange binary: in the case of filling allocated memory with some values the compiler produces 0-value assignments instead of assignment actual variables. Attached is the simple example showing the problem. To compile it use g++ with simple options: g++ -c -Wextra -Wall -O3 -o OverloadedNewGccBug.o OverloadedNewGccBug.cpp g++ -o Test OverloadedNewGccBug.o Then run the Test executable.
[Bug middle-end/91753] Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #2 from Wilco --- (In reply to Andrew Pinski from comment #1) > lower-subreg should have be able to help here. I wonder why it did not ... I'm not sure how it can help. When you write a part of a multi-register mode using subreg, you get incorrect liveness info. This is why splitting 64-bit types on 32-bit targets before register allocation gives such a huge gain. The approach I used in other compilers was to generate multi-register virtual registers using a single create operation rather than via multiple subreg writes.
[Bug c++/91761] Overloaded new operator compiled with -O3 option distorts original C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91761 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- After operator new but before the constructor, the object does not really exist so any values done before the constructor is called are considered as undefined. So GCC is valid in removing them.
[Bug c++/91761] Overloaded new operator compiled with -O3 option distorts original C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91761 Sergey Krasnitsky changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Sergey Krasnitsky --- 1) It doesn't remove these assignments, instead it assigns to 0. 2) No any warning pointing to the unusable assignment. 3) No backward compatibility: worked code now stopped to run.
[Bug c++/91761] Overloaded new operator compiled with -O3 option distorts original C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91761 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #3 from Andrew Pinski --- > 1) It doesn't remove these assignments, instead it assigns to 0. Same thing in reality ... > 2) No any warning pointing to the unusable assignment. There is no way for GCC to do that really. -fsanitize=address -fsanitize=undefined might be able to detect this at runtime; I have not checked. > 3) No backward compatibility: worked code now stopped to run. The code worked on accident. The code was undefined before and after the change. It just happened to work.
[Bug libgomp/91762] New: OpenMP omp target exit data directive not working with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91762 Bug ID: 91762 Summary: OpenMP omp target exit data directive not working with gfortran Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: edoardo.apra at pnnl dot gov CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64 Target: nvptx-none Build: x86_64 Created attachment 46879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46879&action=edit Fortran code to test the OpenMP directive target exit data map(release) The attached test program tests the OpenMP directive target exit data map(release). While a similar C code compiled with gcc shows no execution problem, the compilation with gfortran results in the error code "libgomp: GOMP_target_enter_exit_data unhandled kind 0x04" Here are the instructions for running the attached test code and its only ouput gfortran -fopenmp example1.f ; ./a.out libgomp: GOMP_target_enter_exit_data unhandled kind 0x04
[Bug middle-end/91753] Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753 --- Comment #3 from Andrew Pinski --- (In reply to Wilco from comment #2) > (In reply to Andrew Pinski from comment #1) > > lower-subreg should have be able to help here. I wonder why it did not ... > > I'm not sure how it can help. I think you misunderstood what this pass does. It does exactly what you think it should do: /* Decompose multi-word pseudo-registers into individual pseudo-registers when possible and profitable. This is possible when all the uses of a multi-word register are via SUBREG, or are copies of the register to another location. Breaking apart the register permits more CSE and permits better register allocation. The only difference is the creating part which missing.
[Bug fortran/91717] ICE on concatenating deferred-length character and character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717 --- Comment #5 from Paul Thomas --- Author: pault Date: Fri Sep 13 05:41:01 2019 New Revision: 275696 URL: https://gcc.gnu.org/viewcvs?rev=275696&root=gcc&view=rev Log: 2019-09-13 Paul Thomas PR fortran/91717 * dependency.c (gfc_dep_resolver): Flag identical components and exit with return value 1 if set and no array refs. 2019-09-13 Paul Thomas PR fortran/91717 * gfortran.dg/dependency_55.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_55.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/91717] ICE on concatenating deferred-length character and character literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on trunk Thanks for the PR Paul
