[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 Francois-Xavier Coudert changed: What|Removed |Added Version|7.1.0 |7.2.0 --- Comment #5 from Francois-Xavier Coudert --- Same bug exists with GCC 7.2.0 and GCC 6.4.0, when compiled on a APFS filesystem.
[Bug target/81904] New: FMA and addsub instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81904
Bug ID: 81904
Summary: FMA and addsub instructions
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(asked in
https://stackoverflow.com/questions/45298855/how-to-write-portable-simd-code-for-complex-multiplicative-reduction/45401182#comment77780455_45401182
)
Intel has instructions like vfmaddsubps. Gcc manages, under certain
circumstances, to merge mult and plus or mult and minus into FMA, but not mult
and this strange addsub mix.
#include
__m128d f(__m128d x, __m128d y, __m128d z){
return _mm_addsub_pd(_mm_mul_pd(x,y),z);
}
__m128d g(__m128d x, __m128d y, __m128d z){
return _mm_fmaddsub_pd(x,y,z);
}
(the order of the arguments is probably not right)
My first guess as to how this could be implemented without too much trouble is
in ix86_gimple_fold_builtin: for IX86_BUILTIN_ADDSUBPD and others, check that
we are late enough in the optimization pipeline (roughly where "widening_mul"
is), that contractions are enabled, and that the first (?) argument is a
single-use MULT_EXPR.
I didn't check what the situation is with the vectorizer (which IIRC can now
generate code that ends up as addsub).
[Bug fortran/81898] [7/8 Regression] Issue with polymorphic container class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81898 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-20 CC||janus at gcc dot gnu.org Summary|Issue with polymorphic |[7/8 Regression] Issue with |container class |polymorphic container class Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Here is a further reduced and modified version of the original test case: module AModule implicit none type :: BType end type type:: AType class(BType), allocatable :: obj type(BType), pointer :: bobj contains procedure :: a_rd end type contains subroutine a_rd(this) ! -- dummy class(AType) :: this write(*,*) 'in a_rd' end subroutine end module program main use AModule implicit none class(AType), allocatable, target :: a allocate(a) allocate(a%obj) a%bobj => a%obj write(*,*) 'calling a_rd' call a%a_rd() end It compiles and runs file with gfortran 6 and earlier, but fails with a runtime segfault with gfortran 7 and trunk. Indeed looks like a wrong-code regression.
[Bug fortran/81898] [7/8 Regression] [OOP] Issue with polymorphic container class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81898 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.3 Summary|[7/8 Regression] Issue with |[7/8 Regression] [OOP] |polymorphic container class |Issue with polymorphic ||container class
[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360
--- Comment #3 from Jonathan Wakely ---
If we add this to expression it compiles OK:
expression& operator=(const expression&) { return *this; }
So the invalid instantiation of column::operator=(const column&) comes
from the compiler-generated copy assignment operator. That presumably gets
defined during overload resolution.
I don't know what the difference is between C++98 and C++11 that causes that
(or if it's reasonable to expect a c++11-compat warning).
[Bug libstdc++/81905] New: partial_sort slower than sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81905 Bug ID: 81905 Summary: partial_sort slower than sort Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- (from https://stackoverflow.com/q/45455345/1918193 ) std::partial_sort of half an array can be slower than std::sort of the whole array, because it uses heap sort vs introsort. There may be a size threshold above which we could use a different algorithm than heap_select+sort_heap (say a variant of introsort where after partitioning (possibly with a biased pivot), depending where the pivot ends up, either we partial_sort the left and ignore the right, or we sort the left and partial_sort the right), or some other compromise.
[Bug c++/81901] New: false-positive -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81901
Bug ID: 81901
Summary: false-positive -Warray-bounds
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vermaelen.wouter at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
CC: webrown.cpp at gmail dot com
When switching from gcc-6 to gcc-7 my application triggers some new compiler
warnings (with -Wall). I believe these warnings are false-positives. But I
don't see an easy way to work around them. I also tested with a gcc-8 snapshot
(2017/08/19) and the problem persists.
I managed to reduce my program to the following:
int a[8];
extern void f2();
void f() {
for (int i = 0x3F; i >= 0x10; --i) {
switch (i & 0xF0) {
case 0x00:
if ((i & 0x0F) < 8) a[i] = 0;
break;
case 0x10:
f2();
}
}
}
Compile with
g++ -O2 -Wall test.cpp
warning: array subscript is above array bounds [-Warray-bounds]
[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 --- Comment #3 from Peter Cordes --- Seems to be fixed in gcc7.2.0: https://godbolt.org/g/jRwtZN gcc7.2 is fine with -m32, -mx32, and -m64, but x32 is the most compact. -m64 just calls __atomic_load_16 gcc7.2 -O3 -mx32 output: follow_nounion(std::atomic*): movq(%edi), %rax movl%eax, %eax ret vs. gcc7.1 -O3 -mx32 follow_nounion(std::atomic*): movq(%edi), %rcx xorl%edx, %edx movzbl %ch, %eax movb%cl, %dl movq%rcx, %rsi movb%al, %dh andl$16711680, %esi andl$4278190080, %ecx movzwl %dx, %eax orq %rsi, %rax orq %rcx, %rax ret --- gcc7.2 -O3 -m64 just forwards its arg to __atomic_load_16 and then returns: follow_nounion(std::atomic*): subq$8, %rsp movl$2, %esi call__atomic_load_16 addq$8, %rsp ret It unfortunately doesn't optimize the tail-call to movl$2, %esi jmp __atomic_load_16 presumably because it hasn't realized early enough that it takes zero instructions to extract the 8-byte low half of the 16-byte __atomic_load_16 return value.
[Bug c++/53782] Pointer to static function member expression rejected in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53782 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Eric Gallager --- gcc8 accepts it with neither warning nor error when I try to compile it.
[Bug c++/53972] array constant expression not valid as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53972 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-20 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Huh, there's an extra error message in c++11 compared to c++14: $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=gnu++11 53972.cc 53972.cc: In function ‘int main()’: 53972.cc:27:24: warning: statement has no effect [-Wunused-value] Constify::value; ^ 53972.cc: In instantiation of ‘constexpr char sub1(const char (&)[N], unsigned int) [with unsigned int N = 4]’: 53972.cc:23:15: required from here 53972.cc:10:29: error: ‘array’ is not a constant expression return Constify::value; ^ 53972.cc:10:23: note: in template argument for type ‘unsigned int’ return Constify::value; ~^ 53972.cc:11:1: error: body of constexpr function ‘constexpr char sub1(const char (&)[N], unsigned int) [with unsigned int N = 4]’ not a return-statement } ^ $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=gnu++14 53972.cc 53972.cc: In function ‘int main()’: 53972.cc:27:24: warning: statement has no effect [-Wunused-value] Constify::value; ^ 53972.cc: In instantiation of ‘constexpr char sub1(const char (&)[N], unsigned int) [with unsigned int N = 4]’: 53972.cc:23:15: required from here 53972.cc:10:29: error: ‘array’ is not a constant expression return Constify::value; ^ 53972.cc:10:23: note: in template argument for type ‘unsigned int’ return Constify::value; ~^ $ Confirmed.
[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77732 --- Comment #4 from John David Anglin --- Author: danglin Date: Sun Aug 20 18:23:41 2017 New Revision: 251206 URL: https://gcc.gnu.org/viewcvs?rev=251206&root=gcc&view=rev Log: PR ipa/77732 * gcc.dg/ipa/ipcp-cstagg-7.c: Xfail on 32-bit hppa. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
[Bug c++/54574] G++ accepts parameters with wrong types in parent constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54574
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||egallager at gcc dot gnu.org
Resolution|--- |WORKSFORME
--- Comment #1 from Eric Gallager ---
gcc8 errors as you expected it to:
$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 54574.cc
54574.cc: In instantiation of ‘A::A(int*) [with T = int]’:
54574.cc:16:13: required from here
54574.cc:11:13: error: no matching function for call to ‘C::C(int*&)’
: C (Items) {// C is called with wrong parameter type, expects int**
^
54574.cc:4:3: note: candidate: ‘C::C(int**)’
C (int* Items[]);
^
54574.cc:4:3: note: no known conversion for argument 1 from ‘int*’ to ‘int**’
54574.cc:1:7: note: candidate: ‘constexpr C::C(const C&)’
class C
^
54574.cc:1:7: note: no known conversion for argument 1 from ‘int*’ to ‘const
C&’
54574.cc:1:7: note: candidate: ‘constexpr C::C(C&&)’
54574.cc:1:7: note: no known conversion for argument 1 from ‘int*’ to ‘C&&’
$
[Bug ipa/77732] FAIL: gcc.dg/ipa/ipcp-cstagg-7.c scan-ipa-dump-times cp "Discovered an indirect call to a known target" 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77732 --- Comment #5 from John David Anglin --- Author: danglin Date: Sun Aug 20 18:40:28 2017 New Revision: 251207 URL: https://gcc.gnu.org/viewcvs?rev=251207&root=gcc&view=rev Log: PR ipa/77732 * gcc.dg/ipa/ipcp-cstagg-7.c: Xfail on 32-bit hppa. Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
[Bug c++/45065] -fvisibility-inlines-hidden: Decl order in derived class affects visibility of inlines in base.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45065
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-08-20
CC||egallager at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Eric Gallager ---
(In reply to Dean Edmonds from comment #0)
> Compiling with -fvisibility=hidden and -fvisibility-inlines-hidden.
>
> I have a Base class with default visibility which contains two virtual
> methods, one inlined and the other not. A Derived class with hidden
> visibility overrides the non-inlined method and doesn't touch the inlined
> one. If the declaration of the overridden method appears *before* the
> Derived's virtual destructor then the object file for Derived weakly exports
> the Base class's inlined method. But if the declaration appears *after*
> Derived's virtual destructor then the object for Derived doesn't export the
> Base class's inlined method at all.
>
> Given that I'm compiling with -fvisibility-inlines-hidden I *think* that
> means that the Base class's inlined method should never be exported. Even if
> I'm wrong about that, surely it should not matter the order in which the
> Derived class's methods are declared.
>
> Here's an example which demonstrates the problem:
>
> class __attribute__ ((visibility("default"))) Base
> {
> public:
> Base();
> virtual ~Base();
> virtual void func() const;
> virtual void inlineFunc() {}
> };
>
> class Derived : public Base
> {
> public:
> Derived();
> void func() const;
> virtual ~Derived();
> };
>
> void Derived::func() const
> {}
>
> Compiled on OSX 10.6.4 with g++ 4.2.1, using the following command:
>
> g++-4.2 -Wall -c -arch x86_64 -fvisibility=hidden
> -fvisibility-inlines-hidden -O3 -m64 -isysroot
> /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -o Derived.o
> Derived.cpp
>
> Looking at the object file using 'nm -m Derived.o | grep inlineFunc' gives:
>
> 0010 (__TEXT,__textcoal_nt) weak private external
> __ZN6Common10inlineFuncEv
> 0098 (__TEXT,__eh_frame) weak private external
> __ZN6Common10inlineFuncEv.eh
>
> If I move the declaration of Derived::func() so that it comes after
> ~Derived() then 'nm -m Derived.o | grep inlineFunc' returns nothing.
>
>
On 10.5 with gcc8, the grep only returns one line:
$ /usr/local/bin/g++ -Wall -c -arch x86_64 -fvisibility=hidden
-fvisibility-inlines-hidden -O3 -m64 -isysroot /Developer/SDKs/MacOSX10.5.sdk
-mmacosx-version-min=10.5 -Wextra -pedantic -o 45065.o 45065.cc
$ nm -m 45065.o | grep inlineFunc
0010 (__TEXT,__textcoal_nt) weak private external
__ZN4Base10inlineFuncEv
The difference is no version suffixed with '.eh' so I think it's a 10.5 to 10.6
difference.
> I see similar behaviour on GNU/Linux (2.6.30.9-96.fc11.x86_64) using g++
> 4.4.1. Compiling with this command:
>
> g++ -Wall -c -fvisibility=hidden -fvisibility-inlines-hidden -O3 -m64 -o
> Derived.o Derived.cpp
>
> and using 'objdump -t Derived.o | grep inlineFunc' to inspect the result
> gives this when Derived::func() is declared before ~Derived():
>
> ld .text._ZN4Base10inlineFuncEv
> .text._ZN4Base10inlineFuncEv
> wF .text._ZN4Base10inlineFuncEv 0002
> .hidden _ZN4Base10inlineFuncEv
>
> and gives nothing when Derived::func() is declared after ~Derived().
(In reply to Paolo Carlini from comment #2)
> I can confirm the behavior with today's mainline. And seems weird indeed.
Changing status to NEW then since it's confirmed.
[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037 --- Comment #7 from Jack Howarth --- Created attachment 42011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42011&action=edit proposed back port of changes from trunk for gcc-5-branch
[Bug testsuite/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81056 --- Comment #2 from John David Anglin --- Author: danglin Date: Sun Aug 20 18:52:59 2017 New Revision: 251208 URL: https://gcc.gnu.org/viewcvs?rev=251208&root=gcc&view=rev Log: PR testsuite/81056 * testsuite/17_intro/names.cc: Undef 'd' and 'r' on __hpux__ Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/17_intro/names.cc
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 --- Comment #12 from Jerry DeLisle --- Patch submitted here: https://gcc.gnu.org/ml/fortran/2017-08/msg00045.html
[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037 --- Comment #8 from Jack Howarth --- Verified that proposed changes in PR81037_gcc5.patch with Xcode 8.2.1 on darwin15.6.0 and Xcode 9 beta 5 on 10.13.
[Bug testsuite/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81056 --- Comment #3 from John David Anglin --- Author: danglin Date: Sun Aug 20 19:00:59 2017 New Revision: 251209 URL: https://gcc.gnu.org/viewcvs?rev=251209&root=gcc&view=rev Log: PR testsuite/81056 * testsuite/17_intro/names.cc: Undef 'd' and 'r' on __hpux__. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/testsuite/17_intro/names.cc
[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037 --- Comment #9 from Jack Howarth --- Note that the main deviation from the previous back porting for gcc-6-branch is that the ipa-icf-gimple.c source file must define INCLUDE_LIST since it is used in that file for gcc-5-branch unlike gcc-6-branch.
[Bug testsuite/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81056 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from John David Anglin --- Fixed.
[Bug c++/81906] New: Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
Bug ID: 81906
Summary: Calls to rint() wrongly optimized away starting in g++
6
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Here is a test case:
-- >8 --
#include
#include
#include
int main()
{
printf("--- Test built with gcc %d.%d.%d ---\n",
__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ );
auto const x = -2.5;
printf("Default round mode : rint(%g)=%g\n", x, std::rint(x));
fesetround(FE_DOWNWARD);
printf("Downward round mode: rint(%g)=%g\n", x, std::rint(x));
return 0;
}
-- >8 --
% g++-7 -O1 -Wall -std=c++11 rint.cpp && ./a.out
--- Test built with gcc 7.1.0 ---
Default round mode : rint(-2.5)=-2
Downward round mode: rint(-2.5)=-2
Replacing -O1 with -O0 yields the expected -3 in the last line, but with -O1
(and -O2 etc), the second call to rint() is completely eliminated as can be
seen by examining the generated assembly.
The same bug is also present in 6.4.0 but not in 5.4.1 nor previous versions,
so it looks like rint() has somehow become marked as pure in gcc 6.
[Bug c++/81906] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You want -frounding-math . This option should be specified for programs that change the FP rounding mode dynamically, or that may be executed with a non-default rounding mode.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 Marc Glisse changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2017-08-20 Resolution|INVALID |--- Summary|Calls to rint() wrongly |[7/8 Regression] Calls to |optimized away starting in |rint() wrongly optimized |g++ 6 |away starting in g++ 6 Ever confirmed|0 |1 --- Comment #2 from Marc Glisse --- Indeed you want -frounding-math, and with gcc-6 that makes things work, but starting with gcc-7 it doesn't anymore. (gimple looks fine, the problem comes later)
[Bug c++/53782] Pointer to static function member expression rejected in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53782 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to work||7.2.0, 8.0 Resolution|WORKSFORME |FIXED Known to fail||4.8.0, 5.4.0, 6.3.0 --- Comment #2 from Martin Sebor --- Bisection shows that this bug was fixed in r236221 (GCC 7.0).
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 Roland Illig changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Roland Illig --- Commit r250156 introduced a typo in avr.c: "indentifier" should be "identifier".
[Bug c++/81867] Internal completer error: Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81867 --- Comment #3 from Al Thomason --- I will see if I am able to test using a newer rev, the GCC compiler seems to be rather deeply embedded into the Arduino IDE...
[Bug c/81854] weak alias of an incompatible symbol accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81854 --- Comment #3 from Martin Sebor --- Author: msebor Date: Sun Aug 20 21:31:39 2017 New Revision: 251211 URL: https://gcc.gnu.org/viewcvs?rev=251211&root=gcc&view=rev Log: libstdc++/ChangeLog: PR c/81854 * src/c++98/compatibility.cc (_GLIBCXX_3_4_SYMVER): Declare alias target as a C++ function with no prototype. (_GLIBCXX_3_4_5_SYMVER): Ditto. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++98/compatibility.cc
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #3 from Vadim Zeitlin --- (In reply to Andrew Pinski from comment #1) > You want -frounding-math OK, thanks, this does indeed solve my immediate problem. However is it really normal that the compiler behaviour silently (!) changes like this, in backwards incompatible way between versions? I didn't remember seeing this change mentioned in gcc 6 release notes and I just reread them again and can't find it anywhere. I think changes silently breaking existing working (and standard conforming) code should be at the very least prominently documented (and, of course, ideally completely avoided IMO, but this ship has probably already sailed).
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #4 from Andrew Pinski --- (In reply to Vadim Zeitlin from comment #3) > (In reply to Andrew Pinski from comment #1) > > You want -frounding-math > > OK, thanks, this does indeed solve my immediate problem. However is it > really normal that the compiler behaviour silently (!) changes like this, in > backwards incompatible way between versions? I didn't remember seeing this > change mentioned in gcc 6 release notes and I just reread them again and > can't find it anywhere. I think changes silently breaking existing working > (and standard conforming) code should be at the very least prominently > documented (and, of course, ideally completely avoided IMO, but this ship > has probably already sailed). Yes and no. Since this behavior has been documented this way since 4.4.0: https://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html -frounding-math Disable transformations and optimizations that assume default floating point rounding behavior. This is round-to-zero for all floating point to integer conversions, and round-to-nearest for all other arithmetic truncations. ___This option should be specified for programs that change the FP rounding mode dynamically, or that may be executed with a non-default rounding mode. This option disables constant folding of floating point expressions at compile-time (which may be affected by rounding mode) and arithmetic transformations that are unsafe in the presence of sign-dependent rounding modes. Note I add ___. So basically what changed between 5 and 6 was constant folding of rint. Since that is covered in the documentation, the change itself does not need to be documented as happening.
[Bug c/81141] missing warning using sizeof a/sizeof *a with a zero-length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81141 --- Comment #4 from Martin Sebor --- (In reply to comment #3) What I meant to say is: See also bug 81141 for a related request (limited to strncpy). The patch submitted there issues a warning for a small subset of the problem (strncpy) but doesn't specifically deal with zero-length arrays.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #5 from Vadim Zeitlin --- Yes, I did find this documentation myself in the meanwhile and I agree that you're formally correct, just as gcc developers are formally correct in the long discussion at #34678 (which I really wouldn't want to reopen), but this is not very helpful in practice because this information is completely undiscoverable, i.e. you can only find it if you already know what you're looking for (or enjoy reading compiler optimization options documentation as a hobby, of course). Perhaps you could consider this as a QoI issue, but it would be really great if gcc could give a warning if the code tries to use fesetround() without -frounding-math being on.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #6 from Andrew Pinski --- https://gcc.gnu.org/wiki/FloatingPointMath
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #7 from Vadim Zeitlin --- (In reply to Andrew Pinski from comment #6) > https://gcc.gnu.org/wiki/FloatingPointMath Yes, I've seen this, thanks. But do you think it's easily discoverable? I admit I had even seen this page (and knew about -frounding-math option) before running into this problem after an upgrade to gcc 6 and it still wasn't obvious to me that the problem was due to this. You might just think that I'm abnormally clueless, but it seems to me that most people wouldn't be able to realize the source of the problem immediately. So a warning from the compiler would be really helpful IMO.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #8 from Marc Glisse --- (In reply to Vadim Zeitlin from comment #5) > Perhaps you could consider this as a QoI issue, but it would be really great > if gcc could give a warning if the code tries to use fesetround() without > -frounding-math being on. First note that even with -frounding-math, there are several bugs related to rounding (maybe rint isn't considered pure, but operators like +-*/ are). Also, there are ways (inline asm that hides optimization opportunities) to use fesetround safely even with -fno-rounding-math (and it avoids the perf penalty in places where we don't care about the rounding). Still, I guess we could consider such a warning, if someone is willing to implement it...
[Bug fortran/81296] derived type I/o problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81296 --- Comment #4 from Jerry DeLisle --- Created attachment 42012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42012&action=edit A patch being tested. This patch adds a check for the DT descriptor in the format label. Preliminary test show that this fixes it. Regression testing now.
[Bug middle-end/81907] New: undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907 Bug ID: 81907 Summary: undefined reference to `memset' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dongkyun.s at samsung dot com Target Milestone: --- Created attachment 42013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42013&action=edit memset_test Compiling the attached source without memset trivial implementation, Failed by undefined reference to `memset' OPTFLAGS = -Os -g -mabi=aapcs -fno-function-sections -Wall -mfloat-abi=soft -mtune=cortex-a9 Succeeded with option OPTFLAGS = -Os -g -mabi=aapcs -fno-function-sections -Wall -mfloat-abi=soft -mtune=cortex-a12 Using -O2 instead of -Os (Optimization level) also fix this fail. What is different optimization behavior(implementation) in GCC between cortex-a9 and cortex-a12 -given by mcpu or mtune option ? Found related issue in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888.
[Bug target/81907] undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907 Andrew Pinski changed: What|Removed |Added Keywords|link-failure| Target|arm |arm-*-* Component|middle-end |target Host|x86 | Version|6.3.1 |unknown Build|x86 | --- Comment #1 from Andrew Pinski --- >What is different optimization behavior(implementation) in GCC between >cortex-a9 and cortex-a12 -given by mcpu or mtune option ? Different tuning. Though maybe at -Os should be almost the same except for the allowance for using the instructions that are in cortex-a12 rather than a9 (for the -mcpu case). But really memset is part of the C standard here and you don't use -fno-hoisting option; though IIRC that still requires memset being included in your libc.
[Bug target/81907] undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907 --- Comment #2 from Andrew Pinski --- (In reply to dongkyun.s from comment #0) > Found related issue in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888. Unrelated bug report.
[Bug c/63393] [regression]-ffreestanding not work: memset call cause valgrind crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393 Andrew Pinski changed: What|Removed |Added CC||dongkyun.s at samsung dot com --- Comment #7 from Andrew Pinski --- *** Bug 81907 has been marked as a duplicate of this bug. ***
[Bug target/81907] undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Not a bug, see PR 63393 comment #5 for explanation of why. *** This bug has been marked as a duplicate of bug 63393 ***
[Bug target/81907] undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907
--- Comment #4 from dongkyun.s at samsung dot com ---
Created attachment 42014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42014&action=edit
memset_test_cortex-a9.o (made by '-Os -mtune=cortex-a12')
./gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump
-d memset_test_cortex-a12.o
memset_test_cortex-a12.o: file format elf32-littlearm
Disassembly of section .text:
:
0: b530push{r4, r5, lr}
2: f1a0 0208 sub.w r2, r0, #8
6: 460cmov r4, r1
8: 2300movsr3, #0
a: 2000movsr0, #0
c: 2100movsr1, #0
e: 42a3cmp r3, r4
10: db00blt.n 14
12: bd30pop {r4, r5, pc}
14: f852 5f08 ldr.w r5, [r2, #8]!
18: 3301addsr3, #1
1a: 1940addsr0, r0, r5
1c: eb41 71e5 adc.w r1, r1, r5, asr #31
20: e7f5b.n e
0022 :
22: b51fpush{r0, r1, r2, r3, r4, lr}
24: 2200movsr2, #0
26: 490cldr r1, [pc, #48] ; (58 )
28: 2300movsr3, #0
2a: e9cd 2300 strdr2, r3, [sp]
2e: e9cd 2302 strdr2, r3, [sp, #8]
32: 780cldrbr4, [r1, #0]
34: 7908ldrbr0, [r1, #4]
36: 4623mov r3, r4
38: 4302orrsr2, r0
3a: e9cd 2300 strdr2, r3, [sp]
3e: 788aldrbr2, [r1, #2]
40: 2300movsr3, #0
42: 4668mov r0, sp
44: f043 0307 orr.w r3, r3, #7
48: 2102movsr1, #2
4a: e9cd 2302 strdr2, r3, [sp, #8]
4e: f7ff fffe bl 0
52: b004add sp, #16
54: bd10pop {r4, pc}
56: bf00nop
58: .word 0x
[Bug fortran/81903] compiler reports a language problem (Invalid character in name at)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81903 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-21 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Slightly reduced test case: Module TestMod_C Implicit None Type :: TestType_A Real :: a End type Type :: TestType_B Real :: a End type Type :: TestType_C Class(TestType_A), Pointer :: TT_A(:) Type(TestType_B), Allocatable :: TT_B(:) End type contains Subroutine SubSetPt(this) class(TestType_C), Intent(InOut), Target :: this integer :: i associate(x=>this%TT_B,y=>this%TT_A) Do i=1,size(x) x(i)%a=>y(i)%a End Do end associate End Subroutine End Module
[Bug target/81907] undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907
dongkyun.s at samsung dot com changed:
What|Removed |Added
Attachment #42014|0 |1
is obsolete||
--- Comment #5 from dongkyun.s at samsung dot com ---
Created attachment 42016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42016&action=edit
obj made by '-Os -mtune=cortex-a9'
./gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump
-d memset_test_cortex-a9.o
memset_test_cortex-a9.o: file format elf32-littlearm
Disassembly of section .text:
:
0: b530push{r4, r5, lr}
2: f1a0 0208 sub.w r2, r0, #8
6: 460cmov r4, r1
8: 2300movsr3, #0
a: 2000movsr0, #0
c: 2100movsr1, #0
e: 42a3cmp r3, r4
10: db00blt.n 14
12: bd30pop {r4, r5, pc}
14: f852 5f08 ldr.w r5, [r2, #8]!
18: 3301addsr3, #1
1a: 1940addsr0, r0, r5
1c: eb41 71e5 adc.w r1, r1, r5, asr #31
20: e7f5b.n e
0022 :
22: b51fpush{r0, r1, r2, r3, r4, lr}
24: 2210movsr2, #16
26: 2100movsr1, #0
28: 4668mov r0, sp
2a: f7ff fffe bl 0
2e: 490aldr r1, [pc, #40] ; (58 )
30: 2200movsr2, #0
32: 780cldrbr4, [r1, #0]
34: 7908ldrbr0, [r1, #4]
36: 4623mov r3, r4
38: 4302orrsr2, r0
3a: 4668mov r0, sp
3c: e9cd 2300 strdr2, r3, [sp]
40: 2300movsr3, #0
42: 788aldrbr2, [r1, #2]
44: f043 0307 orr.w r3, r3, #7
48: 2102movsr1, #2
4a: e9cd 2302 strdr2, r3, [sp, #8]
4e: f7ff fffe bl 0
52: b004add sp, #16
54: bd10pop {r4, pc}
56: bf00nop
58: .word 0x
[Bug target/81907] undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907
--- Comment #6 from dongkyun.s at samsung dot com ---
Created attachment 42017
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42017&action=edit
obj made by '-Os -mtune=cortex-a12'
./gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump
-d memset_test_cortex-a12.o
memset_test_cortex-a12.o: file format elf32-littlearm
Disassembly of section .text:
:
0: b530push{r4, r5, lr}
2: f1a0 0208 sub.w r2, r0, #8
6: 460cmov r4, r1
8: 2300movsr3, #0
a: 2000movsr0, #0
c: 2100movsr1, #0
e: 42a3cmp r3, r4
10: db00blt.n 14
12: bd30pop {r4, r5, pc}
14: f852 5f08 ldr.w r5, [r2, #8]!
18: 3301addsr3, #1
1a: 1940addsr0, r0, r5
1c: eb41 71e5 adc.w r1, r1, r5, asr #31
20: e7f5b.n e
0022 :
22: b51fpush{r0, r1, r2, r3, r4, lr}
24: 2200movsr2, #0
26: 490cldr r1, [pc, #48] ; (58 )
28: 2300movsr3, #0
2a: e9cd 2300 strdr2, r3, [sp]
2e: e9cd 2302 strdr2, r3, [sp, #8]
32: 780cldrbr4, [r1, #0]
34: 7908ldrbr0, [r1, #4]
36: 4623mov r3, r4
38: 4302orrsr2, r0
3a: e9cd 2300 strdr2, r3, [sp]
3e: 788aldrbr2, [r1, #2]
40: 2300movsr3, #0
42: 4668mov r0, sp
44: f043 0307 orr.w r3, r3, #7
48: 2102movsr1, #2
4a: e9cd 2302 strdr2, r3, [sp, #8]
4e: f7ff fffe bl 0
52: b004add sp, #16
54: bd10pop {r4, pc}
56: bf00nop
58: .word 0x
[Bug inline-asm/81890] asm memory constraints are difficult and not well documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81890 Alan Modra changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2017-08/msg01174.ht ||ml Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug target/81907] undefined reference to `memset'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907
dongkyun.s at samsung dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #7 from dongkyun.s at samsung dot com ---
> Different tuning. Though maybe at -Os should be almost the same except for
> the allowance for using the instructions that are in cortex-a12 rather than
> a9 (for the -mcpu case).
I attached .o files made by '-mtune=cortex-a9' and 'mtune=cortex-a12' (same as
-mcpu case).
Could you describe more in detail about this why memset is added on cortex-a9
or below ?
memset_test_cortex-a9.o: file format elf32-littlearm
Disassembly of section .text:
...
0022 :
22: b51fpush{r0, r1, r2, r3, r4, lr}
24: 2210movsr2, #16
26: 2100movsr1, #0
28: 4668mov r0, sp
2a: f7ff fffe bl 0
> But really memset is part of the C standard here and you don't use
> -fno-hoisting option;
Which option do you mean? (I'm sorry, but, fno-hoisting is not found)
> Not a bug, see PR 63393 comment #5 for explanation of why.
This is not related to freestanding implementations. Again, option is different
by '-mcpu or -mtune' only.
(1) CFLAGS: -Os -mtune=cortex-a9
(CC) memset_test.o
(CC) main.o
gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-ld
-Bstatic -o memset_test \
memset_test.o main.o \
--start-group
-L/home/dongkyun.s/tmp/memset_test/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/6.3.1
-lgcc --end-group -Map memset_test.map #--gc-sections
memset_test.c:(.text+0x2a): undefined reference to `memset'
(2) CFLAGS: -Os -mtune=cortex-a12
(CC) memset_test.o
(CC) main.o
gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-ld
-Bstatic -o memset_test \
memset_test.o main.o \
--start-group
-L/home/dongkyun.s/tmp/memset_test/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/6.3.1
-lgcc --end-group -Map memset_test.map #--gc-sections
BUILD_TARGETS=memset_test.bin memset_test.txt memset_test.dis memset_test.ver
Build Done!
[Bug target/81907] memset called when it does not need to be; -mtune=cortex-a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Summary|undefined reference to |memset called when it does |`memset'|not need to be; ||-mtune=cortex-a9 Severity|normal |enhancement --- Comment #8 from Andrew Pinski --- >This is not related to freestanding implementations. Huh? Since you are not linking against the C library, it has to be. or you mean this should be optimized not to use memset; different question from what your summary is about.
[Bug target/81907] memset called when it does not need to be; -mtune=cortex-a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81907 --- Comment #9 from dongkyun.s at samsung dot com --- > or you mean this should be optimized not to use memset; different question > from what your summary is about. I mean -ffreestanding or -fno-freestanding are not included in this testcase, but, mtune/ mcpu option. Thanks!
