[Bug c++/25751] Poor error when templating on undefined types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25751 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #4 from Paolo Carlini --- Not actively working on it.
[Bug middle-end/85599] Function need not be evaluated in logical expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW Component|fortran |middle-end Summary|invalid optimization: |Function need not be |function not always |evaluated in logical |evaluated in logical|expression |expression | --- Comment #13 from Thomas Koenig --- In the original test case, it is not necessary to evaluate the function at all. A function evaluation should always be cheaper than just checking a variable. Constant propagation would then eliminate all of the test case, leading only to the effect of flag = .false. As a more realistic example, one should change subroutine foo(a,b) logical, intent(in) :: a logical, intent(out) :: b b = func() .and. a end subroutine foo to subroutine foo(a,b) logical, intent(in) :: a logical, intent(out) :: b if (a) then b = func() else b = .false. end if end subroutine We are passing TRUTH_AND_EXPR to the middle end to allow such optimizations. Is there something in the semantics of TRUTH_AND_EXPR (for example needed for other languages) that says that the function check() needs to be called? Or is this simply some optimization opportunity that is currently not taken?
[Bug ada/85638] [8/9 regression] build failure for Ada runtime with SJLJ exceptions on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638 Eric Botcazou changed: What|Removed |Added Attachment #44066|0 |1 is obsolete|| --- Comment #13 from Eric Botcazou --- Created attachment 44081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44081&action=edit Tentative fix v2 To be tested.
[Bug fortran/85675] New: parameters from other modules in openmp default(none) not specified in enclosing 'parallel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85675 Bug ID: 85675 Summary: parameters from other modules in openmp default(none) not specified in enclosing 'parallel' Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daanvanvugt at gmail dot com Target Milestone: --- I have been experiencing an issue (for a few versions already) related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 but in the case where the parameter is imported from a module in a different source file. c.f90: module c integer, parameter :: n = 100 integer, parameter :: ns(n) = 0 end module c test.f90: program test use c implicit none integer :: i !$omp parallel do default(none) private(i) do i=1,n write(*,*) ns(i) end do !$omp end parallel do end program test gfortran -fopenmp -c c.f90 gfortran -fopenmp -c test.f90 test.f90:8:0: write(*,*) ns(i) Error: ‘ns’ not specified in enclosing ‘parallel’ test.f90:6:0: !$omp parallel do default(none) private(i) Error: enclosing ‘parallel’
[Bug rtl-optimization/85638] [8/9 regression] build failure for Ada runtime with SJLJ exceptions on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638 Eric Botcazou changed: What|Removed |Added Component|ada |rtl-optimization --- Comment #14 from Eric Botcazou --- Recategorizing.
[Bug c/85676] New: Obsolete function declarations should have warnings by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85676 Bug ID: 85676 Summary: Obsolete function declarations should have warnings by default Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david at westcontrol dot com Target Milestone: --- There are a number of features of C that are still legal code even in C11, but have been obsolete for many generations of C because they are unnecessary and have a high risk of errors. gcc has to be able to support old code, but it is perfectly valid to give warnings on such old code. A prime example is non-prototype function declarations, such as "void foo()". This has been obsolete since C89, almost 30 years ago, yet if you have: // a.c void foo(); gcc -std=c11 -Wall -Wextra -pedantic -c a.c it compiles without warning. You need "-Wstrict-prototypes" to get a warning. Surely this warning ought to be part of -Wall, or enabled by default when a C11 or C99 standard is chosen? The same applies to K&R style function definitions.
[Bug testsuite/85677] New: [openacc] gomp-constants.h not available in installed testing of libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85677
Bug ID: 85677
Summary: [openacc] gomp-constants.h not available in installed
testing of libgomp
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I've added quite a few "#include " to libgomp openacc
testcases in r259850.
That worked fine for buildarea testing, but broke those test-cases for
installed testing.
In the build-area testing setup, the compiler can find gomp-constants.h because
in libgomp.exp we find:
...
if { $blddir != "" } {
...
# The top-level include directory, for gomp-constants.h.
lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
}
...
but this line is not active for installed testing.
[Bug c/85678] New: -fno-common should be default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 Bug ID: 85678 Summary: -fno-common should be default Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david at westcontrol dot com Target Milestone: --- The use of a "common" section to match up tentative object definitions in different translation units in a program is contrary to the C standards (section 6.9p5 in C99 and C11, section 6.7 in C90), gives a high risk of error, may lead to poorer quality code, and provides no benefits except backwards compatibility with ancient code. Unix C compilers have traditionally allowed "int x;" in file a.c to be allocated by the linker to the same storage as "int x;" in file b.c when these two C files are linked together. gcc supports this if "-fcommon" is enabled, which is the default on most targets. But it is contrary to the C (and C++) standards that say there shall be exactly /one/ definition of each object. And it is very easy to have errors in code by accidentally having duplicate names in different files (if the programmer has not used "static"), perhaps even of different types. With "-fno-common", such errors are caught at link time. Also, data in common sections will hinder some types of optimisation, such as "-fsection-anchors". Surely it is time to make "-fno-common" the default, at least when a modern C standard is specified indicating that the code is modern? People who need the old behaviour can always get it with "-fcommon".
[Bug testsuite/85677] [openacc] gomp-constants.h not available in installed testing of libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85677 --- Comment #1 from Tom de Vries --- Author: vries Date: Mon May 7 11:33:45 2018 New Revision: 259992 URL: https://gcc.gnu.org/viewcvs?rev=259992&root=gcc&view=rev Log: [openacc, testsuite] Allow installed testing of libgomp to find gomp-constants.h 2018-05-07 Tom de Vries PR testsuite/85677 * testsuite/lib/libgomp.exp (libgomp_init): Move inclusion of top-level include directory in ALWAYS_CFLAGS out of $blddir != "" condition. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/lib/libgomp.exp
[Bug testsuite/85677] [openacc] gomp-constants.h not available in installed testing of libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85677 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug libstdc++/85671] Lack of `std::move()` inside `operator/` for `std::filesystem::path`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-05-07 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It would be better to do: path __tmp(__lhs); __tmp /= __rhs; return __tmp; That allows a copy to be elided.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-07
Summary|error: redefinition of |[9 Regression] error:
|'constexpr long double |redefinition of 'constexpr
|std::abs(long double)' |long double std::abs(long
||double)'
Ever confirmed|0 |1
--- Comment #3 from Jonathan Wakely ---
Yes it woud have been broken by r259813 and this should fix it:
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -342,7 +342,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct __is_floating_point_helper
: public true_type { };
-#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)
+#if !defined(__STRICT_ANSI__) && _GLIBCXX_USE_FLOAT128
template<>
struct __is_floating_point_helper<__float128>
: public true_type { };
[Bug c++/85679] New: __is_trivially_copyable returns false with volatile scalar type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85679
Bug ID: 85679
Summary: __is_trivially_copyable returns false with volatile
scalar type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: flast at flast dot jp
Target Milestone: ---
__is_trivially_copyable builtin returns true on volatile-qualified trivially
copyable class, or array of the class as expected. But not for
volatile-qualified scalar type, such as `int volatile`.
n4741 6.7 [basic.types] p.9 says:
> Cv-unqualified scalar types, trivially copyable class types (Clause 12),
> arrays of such types, and cv-qualified versions of these types are
> collectively
> called trivially copyable types.
i.e. following code should be compiled.
struct S{};
static_assert(__is_trivially_copyable(S volatile));
static_assert(__is_trivially_copyable(S volatile[]));
static_assert(__is_trivially_copyable(S const volatile));
static_assert(__is_trivially_copyable(S const volatile[]));
static_assert(__is_trivially_copyable(int volatile));
static_assert(__is_trivially_copyable(int volatile[]));
static_assert(__is_trivially_copyable(int const volatile));
static_assert(__is_trivially_copyable(int const volatile[]));
https://wandbox.org/permlink/IZ7eCzSFGeSujJPx
See also:
- http://wg21.link/cwg496
- http://wg21.link/cwg1746
- http://wg21.link/cwg2094
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #4 from Marc Glisse --- (In reply to Jonathan Wakely from comment #3) > Yes it woud have been broken by r259813 and this should fix it: I don't think that's sufficient: - the same code is present in several files - -Wsystem-headers -Wundef will warn - it still leaves a weird situation where _GLIBCXX_USE_FLOAT128 may be 1, 0 or undefined, instead of just 2 choices.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #5 from Jonathan Wakely --- (In reply to Marc Glisse from comment #4) > (In reply to Jonathan Wakely from comment #3) > > Yes it woud have been broken by r259813 and this should fix it: > > I don't think that's sufficient: > - the same code is present in several files Only two. include/bits/std_abs.h and include/std/type_traits > - -Wsystem-headers -Wundef will warn That's the status quo. It would take a ton of effort to avoid -Wundef warnings in libstdc++ and that's not something I'm going to work on. > - it still leaves a weird situation where _GLIBCXX_USE_FLOAT128 may be 1, 0 > or undefined, instead of just 2 choices. Ah yes, good point. So we could either change include/Makefile.am to #undef it instead of setting it to 0, or do: --- a/libstdc++-v3/include/bits/c++config +++ b/libstdc++-v3/include/bits/c++config @@ -611,7 +611,10 @@ namespace std /* Define if __float128 is supported on this host. */ #define _GLIBCXX_USE_FLOAT128 -#if !defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__) +#if _GLIBCXX_USE_FLOAT128 == 0 +#undef _GLIBCXX_USE_FLOAT128 +#endif +#elif !defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__) #undef _GLIBCXX_USE_FLOAT128 #endif I think I'd prefer to change include/Makefile.am Then no changes to and would be needed.
[Bug libstdc++/85670] `std::filesystem` does not compile on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85670 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Thanks. I plan to add MinGW support for filesystem in the next week or two, so this is useful.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > (In reply to Marc Glisse from comment #4) > > - -Wsystem-headers -Wundef will warn > > That's the status quo. It would take a ton of effort to avoid -Wundef > warnings in libstdc++ and that's not something I'm going to work on. In other words, don't use -Wsystem-headers -Wundef
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #7 from Marc Glisse --- (In reply to Jonathan Wakely from comment #5) > > - -Wsystem-headers -Wundef will warn > > That's the status quo. It would take a ton of effort to avoid -Wundef > warnings in libstdc++ and that's not something I'm going to work on. I was only listing it as a way to introduce the next point, you can forget it. > > - it still leaves a weird situation where _GLIBCXX_USE_FLOAT128 may be 1, 0 > > or undefined, instead of just 2 choices. > > Ah yes, good point. So we could either change include/Makefile.am to #undef > it instead of setting it to 0, or do: > > --- a/libstdc++-v3/include/bits/c++config > +++ b/libstdc++-v3/include/bits/c++config > @@ -611,7 +611,10 @@ namespace std > > /* Define if __float128 is supported on this host. */ > #define _GLIBCXX_USE_FLOAT128 > -#if !defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__) > +#if _GLIBCXX_USE_FLOAT128 == 0 > +#undef _GLIBCXX_USE_FLOAT128 > +#endif > +#elif !defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__) > #undef _GLIBCXX_USE_FLOAT128 > #endif > > > I think I'd prefer to change include/Makefile.am > > Then no changes to and would be needed. Yes, or maybe don't generate #define _GLIBCXX_USE_FLOAT128 0 but instead /* #undef _GLIBCXX_USE_FLOAT128 */ as we used to do and as the rest of the c++config.h file does. Actually, I am not sure why r259813 needed to change so many things...
[Bug libstdc++/85671] Lack of `std::move()` inside `operator/` for `std::filesystem::path`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 --- Comment #2 from Liu Hao --- 在 2018/5/7 20:13, redi at gcc dot gnu.org 写道: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 > > Jonathan Wakely changed: > > What|Removed |Added > > Status|UNCONFIRMED |ASSIGNED > Last reconfirmed||2018-05-07 > Assignee|unassigned at gcc dot gnu.org |redi at gcc dot > gnu.org > Ever confirmed|0 |1 > > --- Comment #1 from Jonathan Wakely --- > It would be better to do: > >path __tmp(__lhs); >__tmp /= __rhs; >return __tmp; > > That allows a copy to be elided. > There is no difference in implementation as long as NRVO is in effect.
[Bug c++/85680] New: Missed optimization for value-init of variable-sized allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680
Bug ID: 85680
Summary: Missed optimization for value-init of variable-sized
allocation
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/g/6yZEKf (compiled with -O3)
char* variableSize(long n) {
auto p = new char[n]();
for (int i = 0; i < n; i++) {
p[i] = 0xff;
}
return p;
}
char* small() {
return variableSize(8);
}
char* large() {
return variableSize(10'000);
}
The variableSize() case generates two calls two memset with the both being
conditional on n > 0 if I'm reading this right), but the two checks are done in
different ways. That may be a second optimizer bug that it missed a
jump-threading opportunity.
variableSize(long):
pushrbx
mov rbx, rdi
calloperator new[](unsigned long)
mov rcx, rax
mov rax, rbx
sub rax, 1
js .L5
lea rax, [rbx-2]
mov edx, 1
mov rdi, rcx
cmp rax, -1
cmovge rdx, rbx
xor esi, esi
callmemset
mov rcx, rax
.L5:
testrbx, rbx
jle .L1
mov rdi, rcx
mov rdx, rbx
mov esi, 255
callmemset
mov rcx, rax
.L1:
mov rax, rcx
pop rbx
ret
Note that when g++ can see the allocation size it *does* elide the initial
memset:
small(): # @small()
push rax
mov edi, 8
call operator new[](unsigned long)
mov qword ptr [rax], -1
pop rcx
ret
large(): # @large()
push rbx
mov edi, 1
call operator new[](unsigned long)
mov rbx, rax
mov esi, 255
mov edx, 1
mov rdi, rax
call memset
mov rax, rbx
pop rbx
ret
Related clang bug: https://bugs.llvm.org/show_bug.cgi?id=37351
[Bug c/85678] -fno-common should be default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think this discussion has been had on either the main gcc mailing list or gcc-patches recently, but I forget the link...
[Bug c/85678] -fno-common should be default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/ml/gcc/2017-09/msg00088.html
[Bug bootstrap/85681] New: r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 Bug ID: 85681 Summary: r259995 breaks bootstrap on x86_64-*-freebsd Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- ../../gcc/gcc/tree-ssa-loop-prefetch.c: In function 'bool should_issue_prefetch_p(mem_ref*)': ../../gcc/gcc/tree-ssa-loop-prefetch.c:1010:54: error: comparison of integer expressions of different signedness: 'long unsigned int' and 'int' [-Werror=sign-compare] && absu_hwi (int_cst_value (ref->group->step)) < PREFETCH_MINIMUM_STRIDE) ../../gcc/gcc/tree-ssa-loop-prefetch.c:1014:4: error: format '%d' expects argument of type 'int', but argument 5 has type 'long int' [-Werror=format=] "Step for reference %u:%u (%d) is less than the mininum " ^ "required stride of %d\n", ~ ref->group->uid, ref->uid, int_cst_value (ref->group->step), cc1plus: all warnings being treated as errors gmake[3]: *** [Makefile:1110: tree-ssa-loop-prefetch.o] Error 1 gmake[3]: Leaving directory '/safe/sgk/gcc/obj/gcc' gmake[2]: *** [Makefile:4662: all-stage2-gcc] Error 2 gmake[2]: Leaving directory '/safe/sgk/gcc/obj'
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Known to fail||9.0
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #1 from Luis Machado --- Working on it.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> ../../gcc/gcc/tree-ssa-loop-prefetch.c: In function 'bool
> should_issue_prefetch_p(mem_ref*)':
> ../../gcc/gcc/tree-ssa-loop-prefetch.c:1010:54: error: comparison of integer
> expressions of different signedness: 'long unsigned int' and 'int'
> [-Werror=sign-compare]
>&& absu_hwi (int_cst_value (ref->group->step)) <
> PREFETCH_MINIMUM_STRIDE)
> ../../gcc/gcc/tree-ssa-loop-prefetch.c:1014:4: error: format '%d' expects
> argument of type 'int', but argument 5 has type 'long int' [-Werror=format=]
> "Step for reference %u:%u (%d) is less than the mininum "
> ^
> "required stride of %d\n",
> ~
> ref->group->uid, ref->uid, int_cst_value (ref->group->step),
>
> cc1plus: all warnings being treated as errors
> gmake[3]: *** [Makefile:1110: tree-ssa-loop-prefetch.o] Error 1
> gmake[3]: Leaving directory '/safe/sgk/gcc/obj/gcc'
> gmake[2]: *** [Makefile:4662: all-stage2-gcc] Error 2
> gmake[2]: Leaving directory '/safe/sgk/gcc/obj'
The obvious patch
Index: gcc/tree-ssa-loop-prefetch.c
===
--- gcc/tree-ssa-loop-prefetch.c(revision 25)
+++ gcc/tree-ssa-loop-prefetch.c(working copy)
@@ -1011,7 +1011,7 @@ should_issue_prefetch_p (struct mem_ref *ref)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
-"Step for reference %u:%u (%d) is less than the mininum "
+"Step for reference %u:%u (%ld) is less than the mininum "
"required stride of %d\n",
ref->group->uid, ref->uid, int_cst_value (ref->group->step),
PREFETCH_MINIMUM_STRIDE);
allows bootstrap to get to
-MMD -MP -MF ./.deps/tree-ssa-loop-prefetch.TPo
../../gcc/gcc/tree-ssa-loop-prefetch.c
../../gcc/gcc/tree-ssa-loop-prefetch.c: In function 'bool
should_issue_prefetch_p(mem_ref*)':
../../gcc/gcc/tree-ssa-loop-prefetch.c:1010:54: error: comparison of integer
expressions of different signedness: 'long unsigned int' and 'int'
[-Werror=sign-compare]
&& absu_hwi (int_cst_value (ref->group->step)) <
PREFETCH_MINIMUM_STRIDE)
cc1plus: all warnings being treated as errors
gmake[3]: *** [Makefile:1110: tree-ssa-loop-prefetch.o] Error 1
gmake[3]: Leaving directory '/safe/sgk/gcc/obj/gcc'
gmake[2]: *** [Makefile:4662: all-stage2-gcc] Error 2
gmake[2]: Leaving directory '/safe/sgk/gcc/obj'
Please backout your patch.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #3 from Luis Machado --- There are a couple fixups needed in there. The second error you ran into was already caught by gcc in the first comment.
[Bug middle-end/85682] New: Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682 Bug ID: 85682 Summary: Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: luis.machado at linaro dot org Reporter: jgreenhalgh at gcc dot gnu.org CC: hjl.tools at gmail dot com, law at redhat dot com, luis.machado at linaro dot org Target Milestone: --- Target: x86-64-none-linux-gnu Hi, our bisect robot spotted failures in gcc.dg/tree-ssa/prefetch-9.c gcc.dg/tree-ssa/prefetch-8.c gcc.dg/tree-ssa/prefetch-7.c gcc.dg/tree-ssa/prefetch-6.c gcc.dg/tree-ssa/prefetch-3.c gcc.target/i386/opt-1.c gcc.target/i386/opt-2.c gcc.dg/tree-ssa/loop-28.c gcc.dg/tree-ssa/prefetch-5.c after revision r259995 on x86-64-none-linux-gnu. Would you mind taking a look?
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #4 from Luis Machado --- Reverted the offending changes for now.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #5 from luisgpm at gcc dot gnu.org --- Author: luisgpm Date: Mon May 7 15:47:14 2018 New Revision: 26 URL: https://gcc.gnu.org/viewcvs?rev=26&root=gcc&view=rev Log: 2018-05-07 Luis Machado PR bootstrap/85681 Revert: 2018-05-07 Luis Machado * config/aarch64/aarch64-protos.h (cpu_prefetch_tune) : New const bool field. * config/aarch64/aarch64.c (generic_prefetch_tune): Update to include prefetch_dynamic_strides. (exynosm1_prefetch_tune): Likewise. (thunderxt88_prefetch_tune): Likewise. (thunderx_prefetch_tune): Likewise. (thunderx2t99_prefetch_tune): Likewise. (qdf24xx_prefetch_tune): Likewise. Set prefetch_dynamic_strides to false. (aarch64_override_options_internal): Update to set PARAM_PREFETCH_DYNAMIC_STRIDES. * doc/invoke.texi (prefetch-dynamic-strides): Document new option. * params.def (PARAM_PREFETCH_DYNAMIC_STRIDES): New. * params.h (PARAM_PREFETCH_DYNAMIC_STRIDES): Define. * tree-ssa-loop-prefetch.c (should_issue_prefetch_p): Account for prefetch-dynamic-strides setting. 2018-05-07 Luis Machado * config/aarch64/aarch64-protos.h (cpu_prefetch_tune) : New const int field. * config/aarch64/aarch64.c (generic_prefetch_tune): Update to include minimum_stride field. (exynosm1_prefetch_tune): Likewise. (thunderxt88_prefetch_tune): Likewise. (thunderx_prefetch_tune): Likewise. (thunderx2t99_prefetch_tune): Likewise. (qdf24xx_prefetch_tune): Likewise. Set minimum_stride to 2048. (aarch64_override_options_internal): Update to set PARAM_PREFETCH_MINIMUM_STRIDE. * doc/invoke.texi (prefetch-minimum-stride): Document new option. * params.def (PARAM_PREFETCH_MINIMUM_STRIDE): New. * params.h (PARAM_PREFETCH_MINIMUM_STRIDE): Define. * tree-ssa-loop-prefetch.c (should_issue_prefetch_p): Return false if stride is constant and is below the minimum stride threshold. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64.c trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/params.h trunk/gcc/tree-ssa-loop-prefetch.c
[Bug middle-end/85682] Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682 --- Comment #1 from Luis Machado --- Will do. I've temporarily reverted the prefetcher changes since it caused x86 bootstrap issues. I'll investigate this alongside it.
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #5 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 15:55:11 2018 New Revision: 260001 URL: https://gcc.gnu.org/viewcvs?rev=260001&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Removed: trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/02_assoc_legendre/check_value.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/legendre_function.tcc trunk/libstdc++-v3/testsuite/special_functions/02_assoc_legendre/check_value.cc
[Bug target/85683] New: [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683
Bug ID: 85683
Summary: [8 Regression] GCC 8 stopped using RMW (Read Modify
Write) instructions on x86[_64]
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dmitry at zend dot com
Target Milestone: ---
GCC 8 stopped generation of RMW instructions and uses 3 instructions instead of
one. Although, this shouldn't affect executed uops, this increases code size
(pressure to instruction decoder and instruction cache) and requires an extra
register (that may cause extra spills and related degradations).
=== test_rmw.c ===
typedef struct _refcounted {
unsigned int refcount;
} refcounted;
typedef struct _value {
refcounted *val;
} value;
extern void value_dtor_func(refcounted *val);
void ptr_dtor(value *ptr)
{
refcounted *ref = ptr->val;
--ref->refcount;
if (ref->refcount == 0) {
value_dtor_func(ref);
}
}
===
$ gcc -O2 -S test_rmw.c
$ cat test_rmw.s
movq(%rdi), %rdi
movl(%rdi), %eax
subl$1, %eax
movl%eax, (%rdi)
je .L4
ret
.L4:
jmp value_dtor_func
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #6 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:17:32 2018 New Revision: 260004 URL: https://gcc.gnu.org/viewcvs?rev=260004&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Modified: trunk/libstdc++-v3/ChangeLog
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #7 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:19:34 2018 New Revision: 260005 URL: https://gcc.gnu.org/viewcvs?rev=260005&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Backport from mainline 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #8 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:23:29 2018 New Revision: 260006 URL: https://gcc.gnu.org/viewcvs?rev=260006&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Jonathan Wakely Backport from mainline 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::operator()): Fix magic number used in loop condition. (gamma_distribution::__generate_impl()): Ditto. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/random.tcc
[Bug c++/85684] New: output of instrinsic _xgetbv is wrongly overwritten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85684
Bug ID: 85684
Summary: output of instrinsic _xgetbv is wrongly overwritten
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gregory.hainaut at gmail dot com
Target Milestone: ---
Hello,
GCC8.0 adds the long long _xgetbv(unsigned int), however the output isn't taken
into account. xgetbv should return values in rdx:rax (edx:eax in 32 bits).
The following code snippet
#include
#include
int main()
{
if ((_xgetbv(0) & 6) == 6)
printf("Yes\n");
else
printf("No\n");
return 0;
}
will compile as (g++ -mavx2), xgetbv in O0 build
...
xgetbv
movq %rsi, %rax
andl $6, %eax
cmpq $6, %rax
sete %al
testb %al, %al
je .L2
...
Note: the full code is optimized in -O1 as only 2 instructions !
main:
movl $0, %ecx
xgetbv
Best regards
[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/85683] [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683
Alexander Monakov changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-07
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Smaller testcase:
void f(void);
void g(int *p)
{
if (!--*p)
f();
}
On gcc-7.3 this is optimized by the peephole2 pass so it doesn't really help
with register pressure (combine pass seems more suitable for that); don't know
why the peephole doesn't trigger on gcc-8.
[Bug target/85616] ARM target using -O2 may cause unaligned access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85616 --- Comment #4 from Denis Roux --- I agree that the given example code is breaking the C strict aliasing rule. However, I do not believe that the issue I'm reporting is related to aliasing. Further more, adding -fno-strict-aliasing option do not alter the output. The issue I'm having with the optimized code is that it got optimized from 2 store instructions that do not have alignment restriction into 1 multi-store instruction the does have alignment restriction. I would have expected that the optimization would have occurred only if the alignment was guaranteed to be respected.
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #9 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon May 7 16:59:08 2018 New Revision: 260008 URL: https://gcc.gnu.org/viewcvs?rev=260008&root=gcc&view=rev Log: 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> Moar PR libstdc++/80506 * include/bits/random.tcc (gamma_distribution::__generate_impl()): Fix magic number used in loop condition. Actually put the file in. Don't know what my problem is today... Modified: trunk/libstdc++-v3/include/bits/random.tcc
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #6 from Luis Machado --- Would you please confirm the bootstrap is back to normal and declare it resolved? I don't have permission to change its state.
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 --- Comment #7 from Steve Kargl --- On Mon, May 07, 2018 at 05:01:59PM +, luis.machado at linaro dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 > > --- Comment #6 from Luis Machado --- > Would you please confirm the bootstrap is back to normal and declare it > resolved? I don't have permission to change its state. > With r259995 reverted, gcc completes bootstrap. Is this the info you want?
[Bug bootstrap/85681] r259995 breaks bootstrap on x86_64-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85681 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Luis Machado from comment #4) > Reverted the offending changes for now. Reverting your patch fixes bootstrap, so closing. Thanks for quick response.
[Bug c++/85680] Missed optimization for value-init of variable-sized allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680 --- Comment #1 from Marc Glisse --- Quite impressive how we do the test in multiple ways, which are not quite equivalent because of the wrapping semantics of unsigned. Maybe if we asserted that the argument of operator new must be less than the size of the address space / 2 after the call... Probably easier to tweak the C++ FE so it generates more consistent comparisons (this would only remove 1 test). [local count: 118111601]: n.0_11 = (sizetype) n_10(D); _14 = operator new [] (n.0_11); _1 = n.0_11 + 18446744073709551615; _15 = (long int) _1; if (_15 < 0) goto ; [11.00%] else goto ; [89.00%] [local count: 118111600]: if (n_10(D) <= 0) goto ; [11.00%] else goto ; [89.00%] [local count: 105119325]: _31 = n.0_11 + 18446744073709551614; _26 = (long int) _31; _22 = _26 >= -1 ? n.0_11 : 1; __builtin_memset (_14, 0, _22); goto ; [11.00%] [local count: 105119324]: __builtin_memset (_14, 255, n.0_11); [local count: 118111600]: return _14;
[Bug libstdc++/85671] Lack of `std::move()` inside `operator/` for `std::filesystem::path`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Mon May 7 17:26:28 2018 New Revision: 260009 URL: https://gcc.gnu.org/viewcvs?rev=260009&root=gcc&view=rev Log: PR libstdc++/85671 allow copy elision in path concatenation By performing the /= operation on a named local variable instead of a temporary the copy made for the return value can be elided. PR libstdc++/85671 * include/bits/fs_path.h (operator/): Permit copy elision. * include/experimental/bits/fs_path.h (operator/): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/fs_path.h trunk/libstdc++-v3/include/experimental/bits/fs_path.h
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #10 from Jonathan Wakely --- (In reply to emsr from comment #5) > Author: emsr > Date: Mon May 7 15:55:11 2018 > New Revision: 260001 > > URL: https://gcc.gnu.org/viewcvs?rev=260001&root=gcc&view=rev > Log: > 2018-05-07 Edward Smith-Rowland <3dw...@verizon.net> > > Moar PR libstdc++/80506 > * include/bits/random.tcc (gamma_distribution::__generate_impl()): > Fix magic number used in loop condition. > > > Removed: > > trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/ > 02_assoc_legendre/check_value.cc > Modified: > trunk/libstdc++-v3/ChangeLog > trunk/libstdc++-v3/include/tr1/legendre_function.tcc > > trunk/libstdc++-v3/testsuite/special_functions/02_assoc_legendre/check_value. > cc This commit seems to be something unrelated, was it committed by mistake?
[Bug fortran/85685] New: [7/8/9 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85685 Bug ID: 85685 Summary: [7/8/9 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions 7/8/9, if source contains an unused class variable. Compiles without that line "... unused". $ cat z1.f90 program p type t integer, pointer :: z end type class(t), allocatable :: unused contains subroutine s(x) type(t) :: x[*] if ( associated(x%z) ) deallocate(x%z) end end $ gfortran-6 -c z1.f90 -fcoarray=lib $ $ gfortran-9-20180506 -c z1.f90 -fcoarray=single $ gfortran-9-20180506 -c z1.f90 -fcoarray=lib z1.f90:9:0: if ( associated(x%z) ) deallocate(x%z) internal compiler error: in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598 0x74e610 gfc_deallocate_scalar_with_status(tree_node*, tree_node*, tree_node*, bool, gfc_expr*, gfc_typespec, bool) ../../gcc/fortran/trans.c:1598 0x7bc806 gfc_trans_deallocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:6943 0x74af27 trans_code ../../gcc/fortran/trans.c:2000 0x7b03f3 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1433 0x7b81da gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1464 0x74b017 trans_code ../../gcc/fortran/trans.c:1916 0x772499 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x772317 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5519 0x772317 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6436 0x7015e0 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x7015e0 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x74832f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85686] New: [8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85686 Bug ID: 85686 Summary: [8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed around 20180218, affects versions 8/9 : $ cat z1.f90 subroutine s(x) character(*) :: x(:) associate (y => 'a'//x) print *, y end associate end $ gfortran-7 -c z1.f90 $ $ gfortran-9-20180506 -c z1.f90 z1.f90:4:0: print *, y internal compiler error: Segmentation fault 0xb9e99f crash_signal ../../gcc/toplev.c:325 0x75333b gfc_conv_scalarized_array_ref ../../gcc/fortran/trans-array.c:3385 0x754049 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc/fortran/trans-array.c:3540 0x781e3d gfc_conv_variable ../../gcc/fortran/trans-expr.c:2737 0x77eb62 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7930 0x7826c9 gfc_conv_string_length(gfc_charlen*, gfc_expr*, stmtblock_t*) ../../gcc/fortran/trans-expr.c:2242 0x74ef56 get_array_charlen ../../gcc/fortran/trans-array.c:6890 0x74efb4 get_array_charlen ../../gcc/fortran/trans-array.c:6833 0x75cde6 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.c:7190 0x7b158f trans_associate_var ../../gcc/fortran/trans-stmt.c:1703 0x7b8721 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2065 0x74afa7 trans_code ../../gcc/fortran/trans.c:1924 0x772499 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x7015e0 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x7015e0 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x74832f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85687] New: ICE in gfc_sym_identifier, at fortran/trans-decl.c:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85687 Bug ID: 85687 Summary: ICE in gfc_sym_identifier, at fortran/trans-decl.c:351 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Feeding F2018 intrinsic function RANK with an illegal argument (t is not a constant or variable) is silently accepted with -std=f2018, but gives an ICE with -std=f2008 or older. $ cat z1.f90 program p type t end type print *, rank(t) end $ cat z2.f90 program p type t integer :: n end type print *, rank(t) end $ gfortran-9-20180506 -c z1.f90 -std=f2018 $ $ gfortran-9-20180506 -c z1.f90 -std=f2008 z1.f90:2:0: type t internal compiler error: Segmentation fault 0xb9e99f crash_signal ../../gcc/toplev.c:325 0x766aa0 gfc_sym_identifier ../../gcc/fortran/trans-decl.c:351 0x767993 build_function_decl ../../gcc/fortran/trans-decl.c:2274 0x76eca3 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1695 0x781e7f gfc_conv_variable ../../gcc/fortran/trans-expr.c:2554 0x77eb62 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7930 0x7853be gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8030 0x77a8c0 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:5273 0x77e5fc gfc_conv_function_expr ../../gcc/fortran/trans-expr.c:6812 0x77eb42 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7922 0x785268 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8057 0x7a5396 gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.c:2585 0x74ae97 trans_code ../../gcc/fortran/trans.c:2044 0x7a2e47 build_dt ../../gcc/fortran/trans-io.c:2027 0x74aeb7 trans_code ../../gcc/fortran/trans.c:2016 0x772499 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x7015e0 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x7015e0 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x74832f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug libstdc++/85671] Lack of `std::move()` inside `operator/` for `std::filesystem::path`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Jonathan Wakely --- (In reply to Liu Hao from comment #2) > There is no difference in implementation as long as NRVO is in effect. There is a difference. Using move(path(__lhs) /= __rhs) has one copy construction and one non-elided move construction. What I've committed to trunk has a copy construction and an elided move construction.
[Bug c++/85680] Missed optimization for value-init of variable-sized allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680 --- Comment #2 from Mathias Stearn --- FYI, I don't think this is a signed/unsigned thing since it also repros with unsigned long https://godbolt.org/g/LTmrpi My initial repo actually used size_t, but I (incorrectly) changed it to long rather than unsigned long based on past experience that compiler authors prefer repros that don't have any #includes and the (IMO) sad fact that size_t still isn't actually part of the language.
[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85323 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 44082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44082&action=edit gcc9-pr85323.patch Untested WIP patch. Still need to add testsuite coverage for the case when both first and second arguments are constant.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #8 from Jonathan Wakely --- (In reply to Marc Glisse from comment #7) > Yes, or maybe don't generate #define _GLIBCXX_USE_FLOAT128 0 but instead /* > #undef _GLIBCXX_USE_FLOAT128 */ as we used to do and as the rest of the > c++config.h file does. All of those are auto-generated. The custom logic for the float128 macro isn't auto-generated. > Actually, I am not sure why r259813 needed to change > so many things... Because changing /* #undef _GLIBCXX_USE_FLOAT128 */ to a #define was done by autoconf, and that gets automatically added at the end of the c++config file after any manual alterations. The new logic that does: #if defined(__FLOAT128__) || defined(__SIZEOF_FLOAT128__) #undef _GLIBCXX_USE_FLOAT128 #endif comes before the automatically added parts. My autotools-fu is too weak to come up with anything better but I'd be very happy if you can suggest something cleaner.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 Jonathan Wakely changed: What|Removed |Added Keywords||build Known to work||8.1.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > The new logic [...] comes before the automatically added parts. And obviously you can't #undef something that hasn't been defined yet.
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #11 from emsr at gcc dot gnu.org --- Yes, I had an ugly morning with svn. Hopefully the bits are rolled back. That chunk is 83140. Ed.
[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506 --- Comment #12 from emsr at gcc dot gnu.org --- Yes, all other stuff is rolled back except for this patch.
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon May 7 19:22:35 2018 New Revision: 260012 URL: https://gcc.gnu.org/viewcvs?rev=260012&root=gcc&view=rev Log: PR c++/85618 - ICE with initialized VLA. * tree.c (vla_type_p): New. * typeck2.c (store_init_value, split_nonconstant_init_1): Check it rather than array_of_runtime_bound_p. Added: trunk/gcc/testsuite/g++.dg/ext/vla20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/tree.c trunk/gcc/cp/typeck2.c
[Bug tree-optimization/71769] Invalid warning from -Wunsafe-loop-optimizations for a finite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71769 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to amker from comment #6) > (In reply to nightstrike from comment #5) > > Could you backport to the branches? > > Well, that's release manager's call. Richard? Guess not...
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon May 7 19:34:59 2018 New Revision: 260013 URL: https://gcc.gnu.org/viewcvs?rev=260013&root=gcc&view=rev Log: PR c++/85618 - ICE with initialized VLA. * tree.c (vla_type_p): New. * typeck2.c (store_init_value, split_nonconstant_init_1): Check it rather than array_of_runtime_bound_p. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/vla20.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-tree.h branches/gcc-8-branch/gcc/cp/tree.c branches/gcc-8-branch/gcc/cp/typeck2.c
[Bug c++/85618] [8/9 Regression] Zero initialized non constant stack array causes internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #10 from Jonathan Wakely --- Created attachment 44083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44083&action=edit Restore previous behaviour of #undef _GLIBCXX_USE_FLOAT128 based on configure checks. This still follows the same approach of custom logic instead of autogenerated macros, but restores the old behaviour when support is absent during configuration.
[Bug c/85676] Obsolete function declarations should have warnings by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85676 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Eric Gallager --- Dup of bug 82922 *** This bug has been marked as a duplicate of bug 82922 ***
[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K&R style is obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 Eric Gallager changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #5 from Eric Gallager --- *** Bug 85676 has been marked as a duplicate of this bug. ***
[Bug target/85593] [6,7,8,9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Known to work||4.6.4 Summary|[5,6,7,8 Regression] GCC on |[6,7,8,9 Regression] GCC on |ARM allocates R3 for local |ARM allocates R3 for local |variable when calling naked |variable when calling naked |function with O2|function with O2 |optimizations enabled |optimizations enabled Known to fail||5.4.1 --- Comment #6 from Eric Gallager --- gcc 5 branch is closed; retitling
[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.2 Summary|[8 Regression] GCC 8|[8/9 Regression] GCC 8 |stopped using RMW (Read |stopped using RMW (Read |Modify Write) instructions |Modify Write) instructions |on x86[_64] |on x86[_64] --- Comment #2 from Jakub Jelinek --- Started with r247992.
[Bug c++/85688] New: Unhelpful fix-it hint for __float128 when using -mno-float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85688
Bug ID: 85688
Summary: Unhelpful fix-it hint for __float128 when using
-mno-float128
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
g++ -c -x c++ - -mno-float128 <<< 'void f() { __float128 f = 0.0; }'
: In function ‘void f()’:
:1:12: error: ‘__float128’ was not declared in this scope
:1:12: note: suggested alternative: ‘__ieee128’
It might be better to say that __float128 support has been disabled by the
-mno-float128 option, or is not supported for this target and set of options.
[Bug c++/85688] Unhelpful fix-it hint for __float128 when using -mno-float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85688
--- Comment #1 from Jonathan Wakely ---
If this is accepted as a bug then I'll create a similar one for the C front
end:
gcc -c -x c - -mno-float128 <<< 'void f() { __float128 f = 0.0; }'
: In function ‘f’:
:1:12: error: unknown type name ‘__float128’; did you mean ‘_Float128’?
[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I'll handle this.
[Bug c++/85689] New: if constexpr compiles false branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85689
Bug ID: 85689
Summary: if constexpr compiles false branch
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msharov at users dot sourceforge.net
Target Milestone: ---
int main (void)
{
if constexpr (false)
static_assert (false, "this should not be compiled");
return 0;
}
g++ 8.1 fails compiling the branch with the static_assert even though if
constexpr condition is false. May be the same as #85149, but still present in
g++ 8.1.0 on Arch.
[Bug bootstrap/32815] crtstuff.c,warning, will always evaluate as 'true'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32815 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to littlestar from comment #5) > (In reply to comment #3) > > > It's known that -O2 contain "-fstrict-aliasing" which has bugs since gcc > > > 3.X. > > Huh? > > from 4.2.1 status report. > PR 32182 -fstrict-aliasing ... > PR 32327 Incorrect stack sharing... > PR 32328 -fstrict-aliasing ... > > ... These are all closed now.
[Bug other/25914] strsignal.c:558: warning: comparison between signed and unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25914 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to John David Anglin from comment #5) > The libiberty version is documented as unsigned and has been this > way for many years. The Open Group has a strawman proposal which may > be submitted to the Austin Group for addition to POSIX in its next > release. It uses a signed int. Did this proposal ever happen?
[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- Is this still relevant now that powerpc and powerpcspe have been split into separate targets?
[Bug target/49656] internal compiler error on Mac OS 10.7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49656 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Eric Gallager --- (In reply to andreas from comment #3) > I just compiled GCC 4.6.1 again without clang after I found out how to do > that. > > By defining > CC = /usr/bin/gcc-4.2 > CPP = /usr/bin/cpp-4.2 > CXX = /usr/bin/g++-4.2 > LD = /usr/bin/gcc-4.2 > before the configure step the Apple GCC is used for compilation. > > If you don't do that, clang will be used on Mac OS with XCode >4 and this > leads to this "internal compiler error". > So, it doesn't seem to be a GCC issue. OK, so closing then.
[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Alias||enable-werror-always --- Comment #10 from Eric Gallager --- alias enable-werror-always
[Bug fortran/85675] parameters from other modules in openmp default(none) not specified in enclosing 'parallel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85675 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf --- The module file c.mod is the same when compiling the units separately or in one file. Probably some internal information is not dumped to the module file or not properly restored when reading the module.
[Bug target/47093] [meta-bug]: broken configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Bug 47093 depends on bug 47098, which changed state. Bug 47098 Summary: i686-openbsd3.0: OBSD_LIB_SPEC missing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47098 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/47098] i686-openbsd3.0: OBSD_LIB_SPEC missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47098 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Eric Gallager --- (In reply to Bernhard Reutner-Fischer from comment #4) > Fixed on the trunk. If trunk was 6 at the time, then this bug is fixed overall, since no older branches are still open.
[Bug other/25914] strsignal.c:558: warning: comparison between signed and unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25914 --- Comment #7 from dave.anglin at bell dot net --- On 2018-05-07 4:05 PM, egallager at gcc dot gnu.org wrote: > Did this proposal ever happen? Yes: http://pubs.opengroup.org/onlinepubs/9699919799/functions/psignal.html
[Bug target/47093] [meta-bug]: broken configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Bug 47093 depends on bug 48904, which changed state. Bug 48904 Summary: x86_64-knetbsd-gnu fails to build https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48904 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/48904] x86_64-knetbsd-gnu fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48904 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Eric Gallager --- (In reply to Bernhard Reutner-Fischer from comment #5) > Fixed on the trunk. If trunk was 6 at the time, then this bug is fixed overall, since no older branches are still open.
[Bug target/47093] [meta-bug]: broken configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Bug 47093 depends on bug 55143, which changed state. Bug 55143 Summary: vms-c.o:(.toc+0x0): undefined reference to `c_default_pointer_mode' (building cc1plus) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55143 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/55143] vms-c.o:(.toc+0x0): undefined reference to `c_default_pointer_mode' (building cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55143 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Eric Gallager --- (In reply to Bernhard Reutner-Fischer from comment #5) > Fixed on the trunk for 5.0. > > Eventual backport including beef-up of the impl is left to the port > maintainers. No previous branches are open for backports so this is fixed for all open branches.
[Bug fortran/85685] [7/8/9 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85685 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||6.4.0 Keywords||ice-on-valid-code Last reconfirmed||2018-05-07 CC||vehre at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |7.4 Known to fail||7.3.0, 8.1.0, 9.0 --- Comment #1 from Dominique d'Humieres --- The assert has been introduced by revision r243021.
[Bug middle-end/54664] expand_gimple_cond warning for predictably small BRANCH_COST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54664 Eric Gallager changed: What|Removed |Added Keywords||build CC||egallager at gcc dot gnu.org Known to fail|4.10.0 |5.0 --- Comment #2 from Eric Gallager --- (In reply to Hans-Peter Nilsson from comment #1) > Also seen for 4.9.1 and 4.10.0 i.e. trunk r212879. 4.10.0 became 5.0
[Bug fortran/85675] parameters from other modules in openmp default(none) not specified in enclosing 'parallel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85675 --- Comment #2 from Harald Anlauf --- Running under the debugger (separate file 2 only): Breakpoint 1, gfc_omp_predetermined_sharing (decl=0xb7c100fc) at ../../trunk/gcc/fortran/trans-openmp.c:152 152 if (VAR_P (decl) && TREE_READONLY (decl) && TREE_STATIC (decl)) (gdb) p decl->base.readonly_flag $10 = 1 (gdb) p decl->base.static_flag $11 = 0 Running on the whole file: (gdb) p decl->base.static_flag $16 = 1
[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683
--- Comment #4 from Jakub Jelinek ---
This seems to work.
--- gcc/config/i386/i386.md.jj 2018-05-02 23:55:44.0 +0200
+++ gcc/config/i386/i386.md 2018-05-07 22:27:18.848705146 +0200
@@ -19285,6 +19285,40 @@
const0_rtx);
})
+;; Likewise for cmpelim optimized pattern.
+(define_peephole2
+ [(set (match_operand:SWI 0 "register_operand")
+ (match_operand:SWI 1 "memory_operand"))
+ (parallel [(set (reg FLAGS_REG)
+ (compare (match_operator:SWI 3 "plusminuslogic_operator"
+ [(match_dup 0)
+ (match_operand:SWI 2 "")])
+ (const_int 0)))
+ (set (match_dup 0) (match_dup 3))])
+ (set (match_dup 1) (match_dup 0))]
+ "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
+ && peep2_reg_dead_p (3, operands[0])
+ && !reg_overlap_mentioned_p (operands[0], operands[1])
+ && !reg_overlap_mentioned_p (operands[0], operands[2])
+ && (mode != QImode
+ || immediate_operand (operands[2], QImode)
+ || any_QIreg_operand (operands[2], QImode))
+ && ix86_match_ccmode (peep2_next_insn (1),
+(GET_CODE (operands[3]) == PLUS
+ || GET_CODE (operands[3]) == MINUS)
+? CCGOCmode : CCNOmode)"
+ [(parallel [(set (match_dup 4) (match_dup 6))
+ (set (match_dup 1) (match_dup 5))])]
+{
+ operands[4] = SET_DEST (XVECEXP (PATTERN (peep2_next_insn (1)), 0, 0));
+ operands[5]
+= gen_rtx_fmt_ee (GET_CODE (operands[3]), GET_MODE (operands[3]),
+ copy_rtx (operands[1]), operands[2]);
+ operands[6]
+= gen_rtx_COMPARE (GET_MODE (operands[4]), copy_rtx (operands[5]),
+ const0_rtx);
+})
+
;; Likewise for instances where we have a lea pattern.
(define_peephole2
[(set (match_operand:SWI 0 "register_operand")
[Bug target/58801] 4.7.2 alpha-dec-vms fails to link java front end due to language independent incpath.c:target_c_incpath referencing lanuage dependent vms.c:vms_c_register_includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58801 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Eric Gallager --- (In reply to Jay from comment #0) > This is likely fixed in versions. > Recording here for either posterity, or to fix in 4.7.newer, or for > people searching the bug database, though anyone trying this target > will probably have any problems and know how to figure this out. > > > Oh, drat, there is 4.7.3. I can check it. All gcc 4 branches are closed, and java has been removed. Closing.
[Bug c++/85680] Missed optimization for value-init of variable-sized allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680 --- Comment #3 from Mathias Stearn --- MSVC and ICC both also handle this poorly: https://godbolt.org/g/i4wMYa https://developercommunity.visualstudio.com/content/problem/246786/poor-codegen-for-value-init-followed-by-explicit-i.html
[Bug jit/66627] [meta-bug] Tracker bug for jit bugs affecting ravi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from David Malcolm --- Looks like Ravi deleted the libgccjit backend: https://github.com/dibyendumajumdar/ravi/issues/142 Closing this one out.
[Bug middle-end/85559] [meta-bug] Improve conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- .
[Bug middle-end/78947] sub-optimal code for (bool)(int ? int : int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78947 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug target/85665] Multiple typos in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez --- Hi Roland, my guess is that these texts are deep within target-specific code, where target maintainers normally do not consult with other maintainers (diagnostic or otherwise) before committing changes to target-specific code and most of those maintainers are not native speakers. Since those messages are very specific, they are rarely seen by users. Given the amount of bugs in GCC, people tend to focus their efforts in other things. Most of these would require a one line change in the code and you can do such changes without any legal papers or approval by maintainers if you have write after approval status. Hence, it may be worth applying for such status, then applying the changes yourself: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps The first time, it may require a bit of effort to setup subversion/git and you may need to submit a patch to get write after approval, but it should be trivial from there onwards.
[Bug fortran/85686] [8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85686 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||ice-on-valid-code Last reconfirmed||2018-05-07 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |8.2 Known to fail||8.1.0, 9.0 --- Comment #1 from Dominique d'Humieres --- Likely revision r257781 (pr84115).
[Bug fortran/85687] ICE in gfc_sym_identifier, at fortran/trans-decl.c:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85687 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (9.0). Note that -std=f2018 is accepted on 8.1 and 9.0 only.
[Bug target/85593] [6,7,8,9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #7 from Austin Morton --- I will certainly give writing a patch a try - but I will disclaim up front that because there is a viable workaround for the issue I was having (patch below [1]), this issue is "resolved" as far as my employer is concerned. Nevertheless, I will attempt to tackle this on a weekend out of curiosity (never had a reason to dig around in compiler guts before). [1] https://marc.info/?l=linux-bluetooth&m=152535913710490&w=2
[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-07
CC||msebor at gcc dot gnu.org
Component|c++ |tree-optimization
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Confirmed. The warning is issued from gimple-ssa-warn-restrict.c for the
following expression:
_68 = &logBuilder + _69;
The offset _69 is in the anti-range ~[-9223372036854775800,
-9223372036854775800] which the warning pass interprets as/transforms into
[-9223372036854775799, -9223372036854775801] (this is the range referenced by
the diagnostic). The builtin_memref::offset_out_of_bounds() function detects
this kind of range and has special code to deal with it but only for references
of ARRAY_TYPE. In the test case, logBuilder is RECORD_TYPE so the special
handling isn't performed. The following lightly tested change adds this
handling for structs as well to avoid the spurious warning.
Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c (revision 260013)
+++ gcc/gimple-ssa-warn-restrict.c (working copy)
@@ -475,7 +475,10 @@ builtin_memref::offset_out_of_bounds (int strict,
/* A temporary, possibly adjusted, copy of the offset range. */
offset_int offrng[2] = { offrange[0], offrange[1] };
- if (DECL_P (base) && TREE_CODE (TREE_TYPE (base)) == ARRAY_TYPE)
+ tree_code basecode = TREE_CODE (TREE_TYPE (base));
+ if (DECL_P (base)
+ && (basecode == ARRAY_TYPE
+ || basecode == RECORD_TYPE))
{
/* Check for offset in an anti-range with a negative lower bound.
For such a range, consider only the non-negative subrange. */
