[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- Hmm, reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0217r3.html it looks like this is intended.
[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848 --- Comment #20 from rguenther at suse dot de --- On Tue, 15 Nov 2016, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848 > > --- Comment #19 from Bill Schmidt --- > I have a patch that solves this problem by always versioning loops when > vectorization is enabled, and also sets up if-conversion for outer loops so > that outer-loop vectorization can succeed as before. Surprisingly, this > didn't > require any changes to the vectorization code to pass the test suite, and I > verified a couple of examples to see that the expected vectorization was > occurring. Heh, that's surprising but all the better! > We still have these regressions: > > > FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects > > scan-tree-dump-times slp1 "basic block vectorized" 1 > > FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times slp1 "basic block > > vectorized" 1 > > Richard, what are your current thoughts on this re: comment #6? I think we should go this route despite this particular regression. The loop should be vectorizable in loop vectorization and I promise to look at the regression. Note that in theory we can also dispatch to BB vectorization from loop vectorization when that failed to catch the vectorization of if-converted code. > I think I should probably submit the current patch for review despite the > regression, while we talk about the effect on SLP vectorization. I'll do this > tomorrow unless I hear otherwise. Yes, I think that's a good idea. Richard.
[Bug middle-end/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-15 CC||ebotcazou at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > I think the problem here is that SLOW_UNALIGNED_ACCESS is sloppily > defined by my port, and defaults.h, to be a constant, but it is then > used with naturally-aligned data, access to which is never slow, and > expected to return false. So it would probably be best to replace the > condition by > > if (!SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg)) > || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode) > && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg))) > || MEM_ALIGN (reg) >= GET_MODE_ALIGNMENT (mode)) > return true; Yes, SLOW_UNALIGNED_ACCESS ought to be invoked only for unaligned accesses, i.e. only when ALIGNMENT < GET_MODE_ALIGNMENT (mode), see e.g. the RTL expander, so your proposed change is the way to go. But I'd rewrite it into: if (!(MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (mode) && SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg))) || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode) && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg return true; I'm going to test it on ARM, which has the same settings as your port, and this will probably also help the SPARC port for the switch to LRA. Vladimir, what do you think?
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #3 from Richard Biener --- Note that -O3 enables -floop-distribute-patterns which detects open-coded memcpy/memmove/memset. The idea is that canonicalizing leads to optimal inline expansion or library code. I'm not sure I would count this as two vs. three memory streams as usually improving things on the store side helps (this is how the current heuristic works). CPUs are usually more store-bandwith limited. But yes, some sort of target specific parameter might help here (number of store streams we can handle).
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Richard Biener changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355 --- Comment #2 from Richard Biener --- if (!SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg)) || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode) && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg))) || MEM_ALIGN (reg) >= GET_MODE_ALIGNMENT (mode)) return true; looks good to me given gcc/defaults.h:#define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT doesn't do that check itself (maybe it and all ports should be fixed instead...)
[Bug middle-end/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355 --- Comment #3 from Eric Botcazou --- (In reply to Richard Biener from comment #2) > if (!SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg)) > || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode) > && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg))) > || MEM_ALIGN (reg) >= GET_MODE_ALIGNMENT (mode)) > return true; > > looks good to me given > > gcc/defaults.h:#define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT > > doesn't do that check itself (maybe it and all ports should be fixed > instead...) The documentation for SLOW_UNALIGNED_ACCESS implicitly says that it's for unaligned accesses only: -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) Define this macro to be the value 1 if memory accesses described by the MODE and ALIGNMENT parameters have a cost many times greater than aligned accesses, for example if they are emulated in a trap handler. and all other uses of SLOW_UNALIGNED_ACCESS in the compiler do it correctly, so it's an isolated bug in lra-constraints.c. That being said, I can make the wording in the documentation stronger.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #35 from Jack Howarth --- Created attachment 40043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40043&action=edit stock /usr/include/os/trace.h from OS X 10.11.6
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #36 from Jack Howarth --- Created attachment 40044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40044&action=edit fixincludes trace.h generated in stage 1 fixincludes trace.h generated in stage 1 on darwin15 using https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #37 from Jack Howarth ---
Created attachment 40045
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40045&action=edit
preprocessed source for sanitizer_mac.cc from stage3
preprocessed source for sanitizer_mac.cc from stage3 generated with...
[Jacks-Mac-Pro:x86_64-apple-darwin15.6.0/libsanitizer/sanitizer_common] root#
/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc
-B/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/lib/ -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../gcc-7-20161114/libsanitizer/sanitizer_common -I.. -I
../../../../gcc-7-20161114/libsanitizer/include -isystem
../../../../gcc-7-20161114/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin15.6.0
-I../../../../gcc-7-20161114/libsanitizer/../libstdc++-v3/libsupc++
-std=gnu++11 -g -O2 -MT sanitizer_mac.lo -MD -MP -MF .deps/sanitizer_mac.Tpo -c
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc
-fno-common -DPIC -o .libs/sanitizer_mac.o --save-temps
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Address Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Address Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Address Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Undefined Behavior Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Undefined Behavior Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Undefined Behavior Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Thread Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Thread Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Thread Sanitizer reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Sanitizer tool reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Sanitizer tool reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Sanitizer tool reported a failure.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Consult syslog for more information.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Consult syslog for more information.");
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
os_trace("Consult syslog for more information.");
../../../../gcc-7-20161114/libs
[Bug debug/78191] [7 regression] ICE in calc_die_sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78191 Eric Botcazou changed: What|Removed |Added Severity|normal |critical
[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2016-11-15 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- I asked on http://stackoverflow.com/questions/40605343/why-does-stdtuple-decompose-into-rvalue-references and it turned out to be a bug after all.
[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 --- Comment #3 from Markus Trippelsdorf --- T.C. wrote: »decltype applied to an identifier declared by a decomposition declaration returns the referenced type, which for the tuple-like case is the exact type returned by std::tuple_element«
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 > > --- Comment #35 from Jack Howarth --- > Created attachment 40043 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40043&action=edit > stock /usr/include/os/trace.h from OS X 10.11.6 Thanks. I've now extracted /usr/include from the latest Command Line Tools for Xcode versions supporting 10.7 - 10.12. Rainer
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #39 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #36 from Jack Howarth --- > Created attachment 40044 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40044&action=edit > fixincludes trace.h generated in stage 1 > > fixincludes trace.h generated in stage 1 on darwin15 using > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html So the fix has worked as expected/designed. Good to have the confirmation. Rainer
[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #4 from TC --- In particular, [dcl.type.simple]/4, bullet 1: > if e is an unparenthesized id-expression naming an lvalue or > reference introduced from the identifier-list of a decomposition > declaration, decltype(e) is the referenced type as given in the > specification of the decomposition declaration ([dcl.decomp]); And [dcl.decomp]/3 specifies that the referenced type for the i-th identifier is std::tuple_element::type: > Otherwise, if the expression std::tuple_size::value is a > well-formed integral constant expression [...] Given the type > Ti designated by std::tuple_element::type, each vi is > a variable of type “reference to Ti” initialized with the > initializer, where the reference is an lvalue reference if > the initializer is an lvalue and an rvalue reference otherwise; > the referenced type is Ti.
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-15 CC||janus at gcc dot gnu.org Known to work||5.4.1, 6.2.0 Summary|segfault allocating |[7 Regression] [OOP] |polymorphic variable with |segfault allocating |polymorphic component with |polymorphic variable with |allocatable component |polymorphic component with ||allocatable component Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I can confirm that the code runs fine with 6.2 and 5.4, but segfaults with trunk. Slightly reduced test case: program p implicit none type ac end type type, extends(ac) :: a integer, allocatable :: b end type type n class(ac), allocatable :: acr(:) end type type(n) :: s,t allocate(a :: s%acr(1)) call nncp(s,t) contains subroutine nncp(self,tg) type(n) :: self, tg allocate(tg%acr(1),source=self%acr(1)) end end
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 janus at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- I suspect it may be caused by Andre's r241885 ...
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #37 from Jack Howarth ---
> Created attachment 40045
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40045&action=edit
> preprocessed source for sanitizer_mac.cc from stage3
>
> preprocessed source for sanitizer_mac.cc from stage3 generated with...
[...]
> error: ‘_Static_assert’ was not declared in this scope
>os_trace("Address Sanitizer reported a failure.");
>^~
What a mess: I initially misunderstood this error. The problem is:
10.11 unconditionally uses _Static_assert, which is C11
only, while sanitizer_mac.cc is compiled with -std=gnu++11. clang++
supports it as an extension, while g++ does not. One could use
#define _Static_assert static_assert
for C++11 and up, and
#define _Static_assert(x)
otherwise. However ...
> ../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:9:
> error: ‘_os_trace_with_buffer’ was not declared in this scope
>os_trace("Address Sanitizer reported a failure.");
> ^
this one is ugly: os_trace expands to _os_trace_, which all call
_os_trace_with_buffer with a NULL payload. That declaration is
disabled if !__BLOCKS__, thus the `was not declared' error ;-(
On 10.12, os_trace goes to an OS_TRACE_CALL macro which expands to
nothing for anything but clang 7.3 and up...
The more I look into this chaos, the more attractive I find your patch
to disable inclusion if !__BLOCKS__. Seems we cannot do
better than achieve the same with much more effort.
Rainer
[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 Markus Trippelsdorf changed: What|Removed |Added Target Milestone|--- |7.0
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #41 from Jack Howarth --- (In reply to r...@cebitec.uni-bielefeld.de from comment #39) > > --- Comment #36 from Jack Howarth --- > > Created attachment 40044 [details] > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40044&action=edit > > fixincludes trace.h generated in stage 1 > > > > fixincludes trace.h generated in stage 1 on darwin15 using > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html > > So the fix has worked as expected/designed. Good to have the confirmation. > > Rainer I see the problem now. Your proposed fix from https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html simply is simply insufficient in the absence of the change proposed in Comment 33... 2016-11-14 Jack Howarth libsanitizer/ PR sanitizer/78267 * sanitizer_common/sanitizer_mac.cc: Include only if compiler supports blocks extension. Index: libsanitizer/sanitizer_common/sanitizer_mac.cc === --- libsanitizer/sanitizer_common/sanitizer_mac.cc (revision 242387) +++ libsanitizer/sanitizer_common/sanitizer_mac.cc (working copy) @@ -34,7 +34,7 @@ extern char **environ; #endif -#if defined(__has_include) && __has_include() +#if defined(__has_include) && __has_include() && defined(__BLOCKS__) #define SANITIZER_OS_TRACE 1 #include #else Otherwise the definition of SANITIZER_OS_TRACE results in libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace().
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #42 from Jack Howarth --- (In reply to Jack Howarth from comment #41) > (In reply to r...@cebitec.uni-bielefeld.de from comment #39) > > > --- Comment #36 from Jack Howarth --- > > > Created attachment 40044 [details] > > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40044&action=edit > > > fixincludes trace.h generated in stage 1 > > > > > > fixincludes trace.h generated in stage 1 on darwin15 using > > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html > > > > So the fix has worked as expected/designed. Good to have the confirmation. > > > > Rainer > > I see the problem now. Your proposed fix from > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html simply is simply > insufficient in the absence of the change proposed in Comment 33... > > 2016-11-14 Jack Howarth > > libsanitizer/ > > PR sanitizer/78267 > * sanitizer_common/sanitizer_mac.cc: Include only if > compiler supports blocks extension. > > > Index: libsanitizer/sanitizer_common/sanitizer_mac.cc > === > --- libsanitizer/sanitizer_common/sanitizer_mac.cc(revision 242387) > +++ libsanitizer/sanitizer_common/sanitizer_mac.cc(working copy) > @@ -34,7 +34,7 @@ > extern char **environ; > #endif > > -#if defined(__has_include) && __has_include() > +#if defined(__has_include) && __has_include() && > defined(__BLOCKS__) > #define SANITIZER_OS_TRACE 1 > #include > #else > > Otherwise the definition of SANITIZER_OS_TRACE results in > libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace(). And of course that change negates the need for a fix-includes at all.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #1 from Chung-Lin Tang --- Sebastian, I'm not sure what your problem is. The atomics in nios2 are implemented by __sync_* functions placed in libgcc. The built-in function expansion inside GCC is aware of this, and __atomic_* functions get mapped to those. Is there anything affecting your use? libatomic is usually supported by those targets with more "rich" atomic instructions, and nios2 in its current form is obviously not one of them.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #2 from Sebastian Huber --- (In reply to Chung-Lin Tang from comment #1) > Sebastian, I'm not sure what your problem is. The atomics in nios2 are > implemented by __sync_* functions placed in libgcc. The built-in function > expansion inside GCC is aware of this, and __atomic_* functions get mapped > to those. Is there anything affecting your use? I think this mapping of __atomic_* functions to __sync_* functions is wrong/outdated. Is this a speciality of the Nios II support? I am not aware of a second target support in GCC which does this. The __sync_* builtins are a legacy API: https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#g_t_005f_005fsync-Builtins > > libatomic is usually supported by those targets with more "rich" atomic > instructions, and nios2 in its current form is obviously not one of them. The libatomic is for architectures which lack atomic instructions.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #43 from Iain Sandoe --- (In reply to Jack Howarth from comment #42) > (In reply to Jack Howarth from comment #41) > > (In reply to r...@cebitec.uni-bielefeld.de from comment #39) > > Otherwise the definition of SANITIZER_OS_TRACE results in > > libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace(). > > And of course that change negates the need for a fix-includes at all. for GCC, in the short-term yes, but as Rainer pointed out earlier - the problem affects other OSS packages when built with GCC (so it would be nice to have the fix). However, if it's not going to be realistically feasible then let's fall back to the simple approach.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #44 from Maxim Ostapenko --- (In reply to Jack Howarth from comment #41) > (In reply to r...@cebitec.uni-bielefeld.de from comment #39) > > > --- Comment #36 from Jack Howarth --- > > > Created attachment 40044 [details] > > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40044&action=edit > > > fixincludes trace.h generated in stage 1 > > > > > > fixincludes trace.h generated in stage 1 on darwin15 using > > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html > > > > So the fix has worked as expected/designed. Good to have the confirmation. > > > > Rainer > > I see the problem now. Your proposed fix from > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html simply is simply > insufficient in the absence of the change proposed in Comment 33... > > 2016-11-14 Jack Howarth > > libsanitizer/ > > PR sanitizer/78267 > * sanitizer_common/sanitizer_mac.cc: Include only if > compiler supports blocks extension. > > > Index: libsanitizer/sanitizer_common/sanitizer_mac.cc > === > --- libsanitizer/sanitizer_common/sanitizer_mac.cc(revision 242387) > +++ libsanitizer/sanitizer_common/sanitizer_mac.cc(working copy) > @@ -34,7 +34,7 @@ > extern char **environ; > #endif > > -#if defined(__has_include) && __has_include() > +#if defined(__has_include) && __has_include() && > defined(__BLOCKS__) > #define SANITIZER_OS_TRACE 1 > #include > #else > > Otherwise the definition of SANITIZER_OS_TRACE results in > libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace(). This is probably insufficient, we would have errors with /usr/include/asl.h (see comment #10 for error messages) on darwin16. Shouldn't we ifdef out asl stuff too in this case?
[Bug middle-end/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355
--- Comment #4 from pipcet at gmail dot com ---
(In reply to Richard Biener from comment #2)
> if (!SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg))
> || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode)
> && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg)))
> || MEM_ALIGN (reg) >= GET_MODE_ALIGNMENT (mode))
> return true;
>
> looks good to me given
>
> gcc/defaults.h:#define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT
>
> doesn't do that check itself (maybe it and all ports should be fixed
> instead...)
Maybe it would make sense to introduce an intermediate function which does both
checks? That would make the code easier to read, and save us having to change
many targets.
bool fast_access(machine_mode mode, int align)
{
return (align >= GET_MODE_ALIGNMENT (mode)
|| !SLOW_UNALIGNED_ACCESS (mode, align));
}
(BTW, how do we deal with the case when we're accessing the last 16-bit word on
a page, and the next 16 bits are no longer mapped? There's a comment that
suggests no 32-bit access would be generated in this case, but I tried it and
it appears to happen).
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > I suspect it may be caused by Andre's r241885 ... I may be wrong, though: It seems like reverting those changes does not solve the problem. Another candidate: r241439. @Andrew: Are you aware of an earlier trunk build where this was still working? If yes, can you give a revision number?
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #46 from Dominique d'Humieres --- Don't forget: > For the record, note that configuring gcc with --disable-libsanitizer > replace an ICE with accept-invalid in pr44348.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #44 from Maxim Ostapenko --- [...] >> Otherwise the definition of SANITIZER_OS_TRACE results in >> libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace(). > > This is probably insufficient, we would have errors with /usr/include/asl.h > (see comment #10 for error messages) on darwin16. Shouldn't we ifdef out asl > stuff too in this case? That's one option. Another would be to keep the darwin_availabilityinternal part of my fixincludes patch, which would do away with the unconditional use of __attribute__((availability)). Rainer
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > > I suspect it may be caused by Andre's r241885 ... > > I may be wrong, though: It seems like reverting those changes does not solve > the problem. > > Another candidate: r241439. Indeed reverting r241439 (on top of the other one) seems to fix the problem, so apparently this one is the culprit.
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 --- Comment #5 from Dominique d'Humieres --- Revision r241433 works, but r241509 does not.
[Bug c++/78361] [7 regression][c++1z] std::__is_referenceable doesn't handle noexcept function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78361 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c/78359] Redeclaration of global variables is not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78359 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Biener --- As Andrew says.
[Bug rtl-optimization/78325] [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325 --- Comment #3 from Maciej W. Rozycki --- I have pushed it through `mips-mti-linux-gnu' regression testing, with the big-endian o32 regular MIPS multilib. It does fix the regressions listed and does not cause any new ones. Thanks for a quick action!
[Bug fortran/78350] ICE in gfc_code2string(): Bad code, at fortran/misc.c:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78350 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-11-15 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- The code in comment 0 compiles with all the version I have tested except 4.9.3 which gives end 1 Internal Error at (1): gfc_code2string(): Bad code and an instrumented version (r239704) which gives ==88942==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040cd90 at pc 0x0001001d05a2 bp 0x7fff5fbfe770 sp 0x7fff5fbfe768 READ of size 8 at 0x6040cd90 thread T0 #0 0x1001d05a1 in mio_expr(gfc_expr**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d05a1) #1 0x1001d1948 in mio_charlen(gfc_charlen**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d1948) #2 0x1001d0216 in mio_typespec(gfc_typespec*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d0216) #3 0x1001d04ab in mio_expr(gfc_expr**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d04ab) #4 0x1001d3d70 in mio_component(gfc_component*, int) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d3d70) #5 0x1001d40de in mio_component_list(gfc_component**, int) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d40de) #6 0x1001d7dc4 in mio_symbol(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d7dc4) #7 0x1001d8921 in write_symbol(int, gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001d8921) #8 0x1001e0b22 in write_symbol0(gfc_symtree*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001e0b22) #9 0x1001e1103 in write_module() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001e1103) #10 0x1001e1552 in dump_module(char const*, int) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001e1552) #11 0x1001e1c32 in gfc_dump_module(char const*, int) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1001e1c32) #12 0x10023e980 in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023e980) #13 0x10038020a in gfc_be_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10038020a) #14 0x103bf0124 in compile_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf0124) #15 0x103bf92ee in do_compile() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf92ee) #16 0x10568dc2f in toplev::main(int, char**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10568dc2f) #17 0x105692be5 in main (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x105692be5) #18 0x7fffe8d83254 in start (/usr/lib/system/libdyld.dylib+0x5254) #19 0xd (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0xd) 0x6040cd90 is located 0 bytes inside of 48-byte region [0x6040cd90,0x6040cdc0) freed by thread T0 here: #0 0x15078e690 in wrap_free.part.0 (/opt/gcc/gcc7a/lib/libasan.3.dylib+0x53690) #1 0x1002a88e0 in resolve_structure_cons(gfc_expr*, int) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002a88e0) #2 0x1002e2aeb in resolve_values(gfc_symbol*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002e2aeb) #3 0x10032dacc in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10032dacc) #4 0x100345881 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100345881) #5 0x1002d548d in resolve_types(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x1002d548d) #6 0x100293315 in gfc_resolve(gfc_namespace*) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x100293315) #7 0x10023e6ac in gfc_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10023e6ac) #8 0x10038020a in gfc_be_parse_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10038020a) #9 0x103bf0124 in compile_file() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf0124) #10 0x103bf92ee in do_compile() (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x103bf92ee) #11 0x10568dc2f in toplev::main(int, char**) (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x10568dc2f) #12 0x105692be5 in main (/opt/gcc/gcc7g/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951+0x105692be5) #13 0x7fffe8d83254 in star
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 --- Comment #16 from Venkataramanan --- GCC7 added early treading pass and gimple thread pass before VRP. When I disable these passes, tree-vrp is able to move the true block same as that of GCC6. It again the tree-if-convert causing the moved block to come back to its original position. Also non canonical gimple gets formed. : _496 = _512 == 2; _495 = red_cost_503 > 0; _494 = _496 & _495; if (_494 != 0) goto ; else goto ; : <== True block. _502 = basket_size_lsm.75_514 + 1; _501 = perm[_502]; _501->a = arc_516; _501->cost = red_cost_503; _498 = ABS_EXPR ; _501->abs_cost = _498; If we turn off tree-if-conversion, the basic block reordering at RTL brings back the block to its position. But we dont see regression since the check is in order. : _344 = _23 == 2; _345 = red_cost_86 > 0; _342 = _344 & _345; if (_342 != 0) goto ; else goto ; This makes me believe that swapping the operands causes the regression.
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 --- Comment #17 from Venkataramanan --- Looking at the check red_cost < 0 && arc->ident == AT_LOWER) || (red_cost > 0 && arc->ident == AT_UPPER The order if-combine created seem to be the best. if (red_cost_86 < 0) goto ; else goto ; : if (_23 == 1) goto ; else goto ; : _340 = _23 == 2; _341 = red_cost_86 > 0; _338 = _340 & _341; if (_338 != 0) goto ; else goto ; : basket_size.5_30 = basket_size; _31 = basket_size.5_30 + 1; basket_size = _31; _32 = perm[_31]; _32->a = arc_47; _32->cost = red_cost_86; _33 = ABS_EXPR ; _32->abs_cost = _33; If red_cost < 0 is false then checking for arc->ident == AT_UPPER first. This is better, since we know red_cost >0 will always be true. Non canonical gimple generated at if conversion : _496 = _512 == 2; _495 = red_cost_503 > 0; _494 = _496 & _495; if (_494 != 0) goto ; else goto ; should be retain the correct order when we swap back to make it canonical ?
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-15
Ever confirmed|0 |1
--- Comment #4 from Richard Biener ---
> The issue is that memcpy must be produced instead of memove which does
> not have optimized version for avx2 x86 and simply uses byte copy.
I'd expected a if (! overlap) memcpy () else byte-copy at least.
Note the loop distribution code doesn't try to be clever in choosing memcpy
over memmove (using dependence analysis). So improving loop distribution
(adding a PKIND_MEMMOVE and conservatively using that from dependence analysis)
is a possibility as well. But we have
(compute_affine_dependence
stmt_a: _2 = par.0_1->x2[i_19][j_20];
stmt_b: par.0_1->x1[i_19][j_20] = _2;
(analyze_overlapping_iterations
(chrec_a = {0, +, 1}_2)
(chrec_b = {0, +, 1}_2)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
(analyze_overlapping_iterations
(chrec_a = i_19)
(chrec_b = i_19)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
(analyze_overlapping_iterations
(chrec_a = 33280)
(chrec_b = 12800)
(analyze_ziv_subscript
)
(overlap_iterations_a = no dependence)
(overlap_iterations_b = no dependence))
) -> no dependence
so I think we could use memcpy for all no dependence cases?
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 --- Comment #18 from rguenther at suse dot de --- On Tue, 15 Nov 2016, venkataramanan.kumar at amd dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 > > --- Comment #17 from Venkataramanan --- > Looking at the check >red_cost < 0 && arc->ident == AT_LOWER) > || (red_cost > 0 && arc->ident == AT_UPPER > > The order if-combine created seem to be the best. > > if (red_cost_86 < 0) > goto ; > else > goto ; > > : > if (_23 == 1) > goto ; > else > goto ; > > : > _340 = _23 == 2; > _341 = red_cost_86 > 0; > _338 = _340 & _341; > if (_338 != 0) > goto ; > else > goto ; > > : > basket_size.5_30 = basket_size; > _31 = basket_size.5_30 + 1; > basket_size = _31; > _32 = perm[_31]; > _32->a = arc_47; > _32->cost = red_cost_86; > _33 = ABS_EXPR ; > _32->abs_cost = _33; > > If red_cost < 0 is false then checking for arc->ident == AT_UPPER first. This > is better, since we know red_cost >0 will always be true. red_cost can be zero. The "bad" order is best (just slower for some still unknown reason).
[Bug middle-end/78306] [CilkPlus] "inlining failed in call to always_inline ‘memset’: function not inlinable" with -fcilkplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78306
--- Comment #4 from rguenther at suse dot de ---
On Mon, 14 Nov 2016, iblue at gmx dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78306
>
> --- Comment #2 from Markus Fenske ---
> Thanks for the suggested workaround. Moving all the always_inline functions
> into a wrapper was no option, because it's not just memset but my code relies
> on avx intrinsics and would be dead slow if I would need a function all for
> every instruction.
>
> So I just removed the cilk sections in ipa-inline-analysis.c and ipa-inline.c
> and compiled my code with gcc-trunk. It compiles and produces the same results
> as with icc and clang.
>
> I'm not an expert in gcc code, but I would propose this patch to solve the
> issue:
>
> Index: gcc/ipa-inline-analysis.c
> ===
> --- gcc/ipa-inline-analysis.c (revision 242386)
> +++ gcc/ipa-inline-analysis.c (working copy)
> @@ -1507,9 +1507,6 @@
> e->inline_failed = CIF_BODY_NOT_AVAILABLE;
>else if (callee->local.redefined_extern_inline)
> e->inline_failed = CIF_REDEFINED_EXTERN_INLINE;
> - else if (cfun && fn_contains_cilk_spawn_p (cfun))
> -/* We can't inline if the function is spawing a function. */
> -e->inline_failed = CIF_CILK_SPAWN;
>else
> e->inline_failed = CIF_FUNCTION_NOT_CONSIDERED;
>gcc_checking_assert (!e->call_stmt_cannot_inline_p
> Index: gcc/ipa-inline.c
> ===
> --- gcc/ipa-inline.c(revision 242386)
> +++ gcc/ipa-inline.c(working copy)
> @@ -368,11 +368,6 @@
>e->inline_failed = CIF_FUNCTION_NOT_INLINABLE;
>inlinable = false;
> }
> - else if (inline_summaries->get (caller)->contains_cilk_spawn)
> -{
> - e->inline_failed = CIF_CILK_SPAWN;
> - inlinable = false;
> -}
>/* Don't inline a function with mismatched sanitization attributes. */
>else if (!sanitize_attrs_match_for_inline_p (caller->decl, callee->decl))
> {
Bootstrapped and tested on x86_64-unknown-linux-gnu (I expect that
->contains_cilk_spawn might be completely dead).
Richard.
[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 --- Comment #19 from Venkataramanan --- (In reply to rguent...@suse.de from comment #18) > On Tue, 15 Nov 2016, venkataramanan.kumar at amd dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200 > > > > --- Comment #17 from Venkataramanan > > --- > > Looking at the check > >red_cost < 0 && arc->ident == AT_LOWER) > > || (red_cost > 0 && arc->ident == AT_UPPER > > > > The order if-combine created seem to be the best. > > > > if (red_cost_86 < 0) > > goto ; > > else > > goto ; > > > > : > > if (_23 == 1) > > goto ; > > else > > goto ; > > > > : > > _340 = _23 == 2; > > _341 = red_cost_86 > 0; > > _338 = _340 & _341; > > if (_338 != 0) > > goto ; > > else > > goto ; > > > > : > > basket_size.5_30 = basket_size; > > _31 = basket_size.5_30 + 1; > > basket_size = _31; > > _32 = perm[_31]; > > _32->a = arc_47; > > _32->cost = red_cost_86; > > _33 = ABS_EXPR ; > > _32->abs_cost = _33; > > > > If red_cost < 0 is false then checking for arc->ident == AT_UPPER first. > > This > > is better, since we know red_cost >0 will always be true. > > red_cost can be zero. The "bad" order is best (just slower for some > still unknown reason). Could be the case red_cost is always > zero but arc->ident is not AT_UPPER, checking like this (arc->ident == AT_UPPER && red_cost > 0) is faster. The static predication also says so red_cost > 0 is 88% true. if (red_cost_86 < 0) goto ; else goto ; ;;succ: 17 [36.0%] (TRUE_VALUE,EXECUTABLE) ;;18 [64.0%] (FALSE_VALUE,EXECUTABLE) ;; basic block 17, loop depth 2, count 0, freq 684, maybe hot ;;prev block 16, next block 18, flags: (NEW, REACHABLE, VISITED) ;;pred: 16 [36.0%] (TRUE_VALUE,EXECUTABLE) if (_23 == 1) goto ; else goto ; ;;succ: 20 [34.0%] (TRUE_VALUE,EXECUTABLE) ;;21 [66.0%] (FALSE_VALUE,EXECUTABLE) ;; basic block 18, loop depth 2, count 0, freq 1217, maybe hot ;;prev block 17, next block 19, flags: (NEW, REACHABLE, VISITED) ;;pred: 16 [64.0%] (FALSE_VALUE,EXECUTABLE) if (red_cost_86 > 0) goto ; else goto ; ;;succ: 19 [87.7%] (TRUE_VALUE,EXECUTABLE) <== ~88% ;;21 [12.3%] (FALSE_VALUE,EXECUTABLE) ;; basic block 19, loop depth 2, count 0, freq 1067, maybe hot ;;prev block 18, next block 20, flags: (NEW, REACHABLE, VISITED) ;;pred: 18 [87.7%] (TRUE_VALUE,EXECUTABLE) if (_23 == 2) goto ; else goto ; ;;succ: 20 [34.0%] (TRUE_VALUE,EXECUTABLE) ;;21 [66.0%] (FALSE_VALUE,EXECUTABLE)
[Bug middle-end/77383] -fcheck-pointer-bounds -mmpx ICE with VLA struct return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77383 --- Comment #2 from Alexander Ivchenko --- I debugged it and I suspect that the problem is in tree_function_versioning (which is used for making instrumented clones of all functions in MPX). Deep inside the logic of tree_function_versioning we do a copy of that statement: *D.1824 = retframe_block (); [return slot optimization] : (gdb) pgg orig_stmt *D.1824 = retframe_block (); [return slot optimization] (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_lhs(orig_stmt))) D.1820 (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_fntype(orig_stmt))) D.1820 And here is the copy of that gimple statement after remap_gimple_stmt (gdb) pgg stmt MEM[(struct block *)D.1842] = retframe_block (); [return slot optimization] (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_lhs(stmt))) D.1837 (gdb) pct TYPE_SIZE(TREE_TYPE(gimple_call_fntype(stmt))) D.1820 where D.1820 is a local identifier from original "main" function (gdb) pct get_containing_scope(TYPE_SIZE(TREE_TYPE(gimple_call_fntype(stmt main (gdb) pct get_containing_scope(TYPE_SIZE(TREE_TYPE(gimple_call_lhs(stmt main.chkp After later on MPX deletes bodies of original functions, expand crashes when trying to make an rtl for D.1820 var_decl
[Bug target/78362] New: [7 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1804 during libgomp build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78362 Bug ID: 78362 Summary: [7 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1804 during libgomp build Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Build: x86_64-pc-linux-gnu Created attachment 40046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40046&action=edit reduced testcase Compiler output: $ /repo/build-trunk-242408-checking-yes-rtl-df-extra-nographite-aarch64/./gcc/cc1 -quiet -O testcase.c testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1804 foo (void) ^~~ 0xb3e687 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl.c:811 0x1057c4d rhs_regno /repo/gcc-trunk/gcc/rtl.h:1804 0x10b368a rhs_regno /repo/gcc-trunk/gcc/config/aarch64/aarch64.md:1632 0x10b368a gen_addsi3(rtx_def*, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/aarch64/aarch64.md:1613 0xa9c2ea expand_binop_directly /repo/gcc-trunk/gcc/optabs.c:1071 0xa9a0d7 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /repo/gcc-trunk/gcc/optabs.c:1151 0x844238 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.c:9515 0x82dc99 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.c:11050 0x83bdee expand_expr /repo/gcc-trunk/gcc/expr.h:276 0x83bdee expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**, rtx_def**, expand_modifier) /repo/gcc-trunk/gcc/expr.c:7684 0x844379 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.c:8526 0x82dc99 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.c:11050 0x846f22 expand_expr /repo/gcc-trunk/gcc/expr.h:276 0x846f22 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.c:8303 0x82dc99 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.c:11050 0xd208a2 expand_expr /repo/gcc-trunk/gcc/expr.h:276 0xd208a2 computation_cost /repo/gcc-trunk/gcc/tree-ssa-loop-ivopts.c:3639 0xd2ed72 get_computation_cost_at /repo/gcc-trunk/gcc/tree-ssa-loop-ivopts.c:5064 0xd33ff7 get_computation_cost /repo/gcc-trunk/gcc/tree-ssa-loop-ivopts.c:5084 0xd33ff7 determine_group_iv_cost_cond /repo/gcc-trunk/gcc/tree-ssa-loop-ivopts.c:5631 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ /repo/build-trunk-242408-checking-yes-rtl-df-extra-nographite-aarch64/./gcc/xgcc -v Using built-in specs. COLLECT_GCC=/repo/build-trunk-242408-checking-yes-rtl-df-extra-nographite-aarch64/./gcc/xgcc Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --without-cloog --without-ppl --without-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-242408-checking-yes-rtl-df-extra-nographite-aarch64 Thread model: posix gcc version 7.0.0 20161115 (experimental) (GCC) I am failing to build the aarch64 crosscompiler with RTL checking enabled due to this.
[Bug libstdc++/78360] missing throw()s in explicit instantiation declarations for has_facet()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78360 --- Comment #1 from Markus Trippelsdorf --- This points to a defect in the P0012R1 implementation: markus@x4 tmp % cat facet.ii struct locale; template bool has_facet(const locale &) throw(); extern template bool has_facet(const locale &); markus@x4 tmp % clang++ -std=c++1z -c facet.ii facet.ii:3:22: error: explicit instantiation of 'has_facet' does not refer to a function template, variable template, member function, member class, or static data member extern template bool has_facet(const locale &); ^ facet.ii:2:26: note: candidate template ignored: could not match 'bool (const locale &) throw()' against 'bool (const locale &)' template bool has_facet(const locale &) throw(); ^ 1 error generated. markus@x4 tmp % g++ -Wall -Wextra -std=c++1z -c facet.ii markus@x4 tmp %
[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848 --- Comment #21 from Bill Schmidt --- Great, thanks. Just realized I need to add a test case yet -- should have this on the list later today.
[Bug fortran/60853] [OOP] Failure to disambiguate generic with unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60853
--- Comment #3 from janus at gcc dot gnu.org ---
This patch makes gfortran accept the code:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (Revision 242412)
+++ gcc/fortran/interface.c (Arbeitskopie)
@@ -1741,9 +1741,6 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol
return 0;
}
- if (UNLIMITED_POLY (f1->sym))
- goto next;
-
if (strict_flag)
{
/* Check all characteristics. */
Regtesting now ...
[Bug c++/78363] New: internal compiler error: in force_type_die, at dwarf2out.c:24864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363
Bug ID: 78363
Summary: internal compiler error: in force_type_die, at
dwarf2out.c:24864
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrey.y.guskov at intel dot com
Target Milestone: ---
Consider the following code snippet (a very abridged version of
libgomp/testsuite/libgomp.c++/pr58706.C):
int main() {
int n = 0;
#pragma omp parallel for reduction (+: n)
for (int i = [](){ return 3; }(); i < 10; ++i)
n++;
return n;
}
This is what happens when I attempt to compile it:
$ build_ext/bin/g++ -v
Using built-in specs.
COLLECT_GCC=//build_ext/bin/g++
COLLECT_LTO_WRAPPER=//build_ext/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: //source/configure --prefix=//build_ext
--with-system-zlib --with-demangler-in-ld --with-fpmath=sse --with-arch=haswell
--with-cpu=haswell --enable-shared --enable-host-shared --enable-clocale=gnu
--enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto
Thread model: posix
gcc version 7.0.0 20161115 (experimental) (GCC)
$ build_ext/bin/g++ fail.cpp -fopenmp –g
fail.cpp: In lambda function:
fail.cpp:6:34: internal compiler error: in force_type_die, at dwarf2out.c:24864
for (int i = [](){ return 3; }(); i < 10; ++i)
^
0xa16d0e force_type_die
//source/gcc/dwarf2out.c:24864
0xa16463 get_context_die
//source/gcc/dwarf2out.c:24778
0xa16463 force_decl_die
//source/gcc/dwarf2out.c:24797
0xa14078 gen_subprogram_die
//source/gcc/dwarf2out.c:21722
0xa14e74 gen_decl_die
//source/gcc/dwarf2out.c:25100
0xa15dfe dwarf2out_decl
//source/gcc/dwarf2out.c:25607
0xa3312e dwarf2out_function_decl
//source/gcc/dwarf2out.c:25622
0xa91dba rest_of_handle_final
//source/gcc/final.c:4508
0xa91dba execute
//source/gcc/final.c:4550
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Without the last ‘-g’ it compiles fine and returns 7, just as expected.
[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346 --- Comment #6 from Arseny Solokha --- (In reply to Aldy Hernandez from comment #5) > -fPIC -fno-stack protector Did you copy your session verbatim in #c5? If so, -f(no-)stack-protector apparently has nothing to do w/ the issue. Your cross-compilers most likely default to -fPIC, and while you negated -fstack-protector, you didn't do the same w/ -fPIC. May I ask you to try it once again the following way: % ./cc1 -quiet a.c -quiet -mno-lra -Os -w -I./ -fno-PIC ?
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
--- Comment #5 from Yuri Rumyantsev ---
Yes, I think so.
2016-11-15 14:49 GMT+03:00 rguenth at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
>
> Richard Biener changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |NEW
>Last reconfirmed||2016-11-15
> Ever confirmed|0 |1
>
> --- Comment #4 from Richard Biener ---
>> The issue is that memcpy must be produced instead of memove which does
>> not have optimized version for avx2 x86 and simply uses byte copy.
>
> I'd expected a if (! overlap) memcpy () else byte-copy at least.
>
> Note the loop distribution code doesn't try to be clever in choosing memcpy
> over memmove (using dependence analysis). So improving loop distribution
> (adding a PKIND_MEMMOVE and conservatively using that from dependence
> analysis)
> is a possibility as well. But we have
>
> (compute_affine_dependence
> stmt_a: _2 = par.0_1->x2[i_19][j_20];
> stmt_b: par.0_1->x1[i_19][j_20] = _2;
> (analyze_overlapping_iterations
> (chrec_a = {0, +, 1}_2)
> (chrec_b = {0, +, 1}_2)
> (overlap_iterations_a = [0])
> (overlap_iterations_b = [0]))
> (analyze_overlapping_iterations
> (chrec_a = i_19)
> (chrec_b = i_19)
> (overlap_iterations_a = [0])
> (overlap_iterations_b = [0]))
> (analyze_overlapping_iterations
> (chrec_a = 33280)
> (chrec_b = 12800)
> (analyze_ziv_subscript
> )
> (overlap_iterations_a = no dependence)
> (overlap_iterations_b = no dependence))
> ) -> no dependence
>
> so I think we could use memcpy for all no dependence cases?
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug debug/78363] internal compiler error: in force_type_die, at dwarf2out.c:24864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363 Andrey Guskov changed: What|Removed |Added Component|c++ |debug --- Comment #1 from Andrey Guskov --- Proved to be independent of --with-arch=haswell --with-cpu=haswell: same error on --with-arch=corei7 --with-cpu=corei7.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #3 from Chung-Lin Tang --- (In reply to Sebastian Huber from comment #2) > (In reply to Chung-Lin Tang from comment #1) > > Sebastian, I'm not sure what your problem is. The atomics in nios2 are > > implemented by __sync_* functions placed in libgcc. The built-in function > > expansion inside GCC is aware of this, and __atomic_* functions get mapped > > to those. Is there anything affecting your use? > > I think this mapping of __atomic_* functions to __sync_* functions is > wrong/outdated. Is this a speciality of the Nios II support? I am not > aware of a second target support in GCC which does this. The __sync_* > builtins are a legacy API: > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins. > html#g_t_005f_005fsync-Builtins Nios II is not the only target which implements __sync_*, see the libgcc source code for details. In the current GCC code expansion paths, the __atomic_* functions are meant to expand to hardware instruction sequences. In cases where we need to generate library calls for atomics, GCC only generates __sync_* calls. > > > > libatomic is usually supported by those targets with more "rich" atomic > > instructions, and nios2 in its current form is obviously not one of them. > > The libatomic is for architectures which lack atomic instructions. To clarify/correct my above statement, we do build libatomic like other targets, but the basic __atomic_* functions used inside it is also generated as __sync_* calls. libatomic does NOT directly "implement" the basic __atomic_* operations, that's supposed to be done inside the compiler. Can you more specifically describe what you're trying to do? Or is this just a general query?
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #4 from Sebastian Huber --- (In reply to Chung-Lin Tang from comment #3) > (In reply to Sebastian Huber from comment #2) > > (In reply to Chung-Lin Tang from comment #1) > > > Sebastian, I'm not sure what your problem is. The atomics in nios2 are > > > implemented by __sync_* functions placed in libgcc. The built-in function > > > expansion inside GCC is aware of this, and __atomic_* functions get mapped > > > to those. Is there anything affecting your use? > > > > I think this mapping of __atomic_* functions to __sync_* functions is > > wrong/outdated. Is this a speciality of the Nios II support? I am not > > aware of a second target support in GCC which does this. The __sync_* > > builtins are a legacy API: > > > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins. > > html#g_t_005f_005fsync-Builtins > > Nios II is not the only target which implements __sync_*, see the libgcc > source code for details. The libgcc is not relevant for code generation as far as I know. I checked the code generation on some targets for the test case above. The arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets generated all __atomic_* functions. > > In the current GCC code expansion paths, the __atomic_* functions are meant > to expand to hardware instruction sequences. In cases where we need to > generate library calls for atomics, GCC only generates __sync_* calls. Only on Nios II it seems, the other targets emit __atomic_* calls. > > > > > > > libatomic is usually supported by those targets with more "rich" atomic > > > instructions, and nios2 in its current form is obviously not one of them. > > > > The libatomic is for architectures which lack atomic instructions. > > To clarify/correct my above statement, we do build libatomic like other > targets, but the basic __atomic_* functions used inside it is also generated > as __sync_* calls. > > libatomic does NOT directly "implement" the basic __atomic_* operations, > that's supposed to be done inside the compiler. > > Can you more specifically describe what you're trying to do? Or is this just > a general query? I don't find any Nios II specific parts in libatomic. Implementing __atomic_* functions via __sync_* in libatomic makes no sense to me. The host specific implementation should provide (libatomic_i.h): /* Locking for a "small" operation. In the bare-metal single processor cases this could be implemented by disabling interrupts. Thus the extra word passed between the two functions, saving the interrupt level. It is assumed that the object being locked does not cross the locking granularity. Not actually declared here so that they can be defined static inline in a target-specfic . UWORD protect_start (void *ptr); void protect_end (void *ptr, UWORD); */ /* Locking for a "large' operation. This should always be some sort of test-and-set operation, as we assume that the interrupt latency would be unreasonably large. */ void libat_lock_n (void *ptr, size_t n); void libat_unlock_n (void *ptr, size_t n);
[Bug debug/78363] [7 Regression] ICE in in force_type_die, at dwarf2out.c:24864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2016-11-15 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|internal compiler error: in |[7 Regression] ICE in in |force_type_die, at |force_type_die, at |dwarf2out.c:24864 |dwarf2out.c:24864 Target Milestone|--- |7.0 Known to fail||6.2.0 --- Comment #2 from Martin Liška --- Confirmed, started with r240578.
[Bug fortran/60853] [OOP] Failure to disambiguate generic with unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60853 janus at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > Regtesting now ... I'm surprised to see that this removal does not cause any regressions. Those lines in gfc_compare_interfaces come from r194622, which apparently was Paul's very first commit to support unlimited polymorphism (back in 2012). I guess the interface checks in compare_type/compare_rank have been refined since then, so that this crutch is not needed any more (in particular since it's wrong ;) Paul, do you agree that the patch in comment 3 is ok to commit?
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug c/78359] Redeclaration of global variables is not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78359 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #6 from Eric Gallager --- (In reply to Andrew Pinski from comment #4) > (In reply to hugo74 from comment #2) > > It should not work that way. I checked it in other C compilers and each of > > them reports an redefinition error in such case. > > Are you sure they were C compilers and not C++ compilers? > > C and C++ differ here. Hence -Wc++-compat gets the warning desired: $ /usr/local/bin/gcc -Wall -Wextra -pedantic -Wredundant-decls -Wc++-compat -fno-common -c pr78359.c pr78359.c:1:14: warning: duplicate declaration of ‘Counter’ is invalid in C++ [-Wc++-compat] int Counter, Counter, Counter; ^~~ pr78359.c:1:5: note: previous declaration of ‘Counter’ was here int Counter, Counter, Counter; ^~~ pr78359.c:1:23: warning: duplicate declaration of ‘Counter’ is invalid in C++ [-Wc++-compat] int Counter, Counter, Counter; ^~~ pr78359.c:1:14: note: previous declaration of ‘Counter’ was here int Counter, Counter, Counter; ^~~
[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78319
--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I think this seems to be an issue with uninit pass.
The same behavior can be observed for following test-case on
x86_64-unknown-linux-gnu regardless of r241915.
(test-case is a slight modification of foo() defined in uninit-pred-8_a.c to
generate same CFG on x86_64 as on cortex-m7):
int f(int n, int m, int l, int r)
{
int t1, t2, t3, t4, v;
extern int g;
void bar();
void blah(int);
if ((n || m) || (r || l))
v = r;
if (m != 0)
g++;
else
bar ();
if ((n || m) || (r || l))
blah (v);
if (n != 0)
blah (v);
if (l != 0)
blah (v);
return 0;
}
-O2 -Wuninitialized gives:
foo2.c: In function ‘f’:
foo2.c:17:5: warning: ‘v’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
blah (v);
^~~~
Input to uninit pass (dump of crited2 pass):
http://pastebin.com/wJBak3tS
v is assigned the value of r if either _1 is true or _2 is true in above cfg.
The warning at uninitialized use of v is for:
if ((n || m) || (r || l))
blah(v);
IIUC, the above call to blah(v) is duplicated in two blocks: bb10 and bb16.
bb10 has only one predecessor bb7.
Looking at:
:
# v_32 = PHI
bar ();
:
# v_33 = PHI
if (_1 != 0)
goto ;
else
goto ;
v is uninitialized if the control reaches to bb6 from bb17, ie
the following path is taken: bb2 -> bb3 -> bb17 -> bb6 -> bb7
This path would be taken only if both _1 and _2 are 0.
Since control goes from bb7 to bb10 only if _1 is nonzero, we can never reach
bb10 if v is uninitialized.
Similarly bb16 has only one predecessor bb8 and bb8 has only one predecessor
bb7.
We reach bb8 from "false edge" of bb7, ie, if _1 is 0.
:
_5 = r_13(D) | l_14(D);
if (_5 != 0)
goto ;
else
goto ;
_5 is same as _2. I wonder why r_13(D) | l_14(D) is re-computed here instead of
using _2, which is assigned the same value ?
So if _5 is false, we should never reach bb16 and hence I think the warning is
a false positive.
Does this sound reasonable ?
Btw the warning isn't given if vrp is disabled.
Input to uninit pass after disabling vrp:
http://pastebin.com/index.php
IIC after disabling vrp, the cfg has only one block bb10 representing
the blah(v) call unlike in the first case of enabled vrp, which duplicated
bb10 and bb16 both containing calls to blah(v).
There's another strange issue I noticed about folding:
Consider following test-case:
int f(int n, int m, int l, int r)
{
if (n || m || r || l)
return 1;
else
return 0;
}
On x86_64,
ssa pass dump shows:
http://pastebin.com/Fuy6dGX1
truth_orif_expr's are converted to sequence of bit_ior_exprs:
:
_1 = n_5(D) | m_6(D);
_2 = l_7(D) | _1;
_3 = r_8(D) | _2;
if (_3 != 0)
goto ;
else
goto ;
However if the expression is parenthesized as:
if ((n || m) || (r || l)) then truth_orif_expr is not converted to sequence of
bit_ior_exprs as above.
x86_64 ssa dump for parenthesized expression:
http://pastebin.com/AsQ5qLFu
:
_1 = n_4(D) | m_5(D);
if (_1 != 0)
goto ;
else
goto ;
:
_2 = l_6(D) | r_7(D);
if (_2 != 0)
goto ;
else
goto ;
Why should parenthesizing the sub-expressions make a difference ?
Thanks,
Prathamesh
[Bug target/77881] [5/6/7 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881 --- Comment #6 from Michael Matz --- Author: matz Date: Tue Nov 15 14:02:28 2016 New Revision: 242414 URL: https://gcc.gnu.org/viewcvs?rev=242414&root=gcc&view=rev Log: PR missed-optimization/77881 * combine.c (simplify_comparison): Remove useless subregs also inside the loop, not just after it. (make_compound_operation): Recognize some subregs as being masking as well. testsuite/ * gcc.target/i386/pr77881.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr77881.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug target/77881] [5/6 Regression] Non-optimal signed comparison on x86_64 since r146817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881 Michael Matz changed: What|Removed |Added Summary|[5/6/7 Regression] |[5/6 Regression] |Non-optimal signed |Non-optimal signed |comparison on x86_64 since |comparison on x86_64 since |r146817 |r146817 --- Comment #7 from Michael Matz --- Fixed for gcc 7. Not planning backports myself , it's a minor code quality regression only. But keeping it open in case anyone else wants to.
[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78295 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Nov 15 13:57:59 2016 New Revision: 242413 URL: https://gcc.gnu.org/viewcvs?rev=242413&root=gcc&view=rev Log: PR middle-end/78295 * gcc.dg/uninit-pr78295.c: Add -Wno-psabi to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/uninit-pr78295.c
[Bug target/78362] [7 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1804 during libgomp build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78362 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-15 CC||ktkachov at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed while trying to build an RTL checking cross compiler
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #5 from Chung-Lin Tang --- > I checked the code generation on some targets for the test case above. The > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets > generated all __atomic_* functions. > Only on Nios II it seems, the other targets emit __atomic_* calls. Many of those target archs use __sync_* by default on Linux, although you might generate __atomic_* on bare metal. That's the case on nios2; we should be generating __atomic_* calls if you're using nios2 ELF (bare metal), for Linux the compiler will generate __sync_* calls, unless the architecture has hardware instructions. > > > > > > > > libatomic is usually supported by those targets with more "rich" atomic > > > > instructions, and nios2 in its current form is obviously not one of > > > > them. > > > > > > The libatomic is for architectures which lack atomic instructions. > > > > To clarify/correct my above statement, we do build libatomic like other > > targets, but the basic __atomic_* functions used inside it is also generated > > as __sync_* calls. > > > > libatomic does NOT directly "implement" the basic __atomic_* operations, > > that's supposed to be done inside the compiler. > > > > Can you more specifically describe what you're trying to do? Or is this just > > a general query? > > I don't find any Nios II specific parts in libatomic. > > Implementing __atomic_* functions via __sync_* in libatomic makes no sense > to me. The host specific implementation should provide (libatomic_i.h): Most architectures don't have library implementations of __atomic_* operations, especially if we already have __sync_*. The major difference is the consistency model arguments in __atomic_* APIs, which is useless for simpler architectures like nios2.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #6 from Sebastian Huber --- (In reply to Chung-Lin Tang from comment #5) > > I checked the code generation on some targets for the test case above. The > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets > > generated all __atomic_* functions. > > > Only on Nios II it seems, the other targets emit __atomic_* calls. > > Many of those target archs use __sync_* by default on Linux, although you > might generate __atomic_* on bare metal. > That's the case on nios2; we should be generating __atomic_* calls if you're > using nios2 ELF (bare metal), for Linux the compiler will generate __sync_* > calls, unless the architecture has hardware instructions. This sounds reasonable. Which magic switch in GCC leads to the generation of __sync_* functions instead of __atomic_* functions? > > > > > > > > > > > libatomic is usually supported by those targets with more "rich" > > > > > atomic > > > > > instructions, and nios2 in its current form is obviously not one of > > > > > them. > > > > > > > > The libatomic is for architectures which lack atomic instructions. > > > > > > To clarify/correct my above statement, we do build libatomic like other > > > targets, but the basic __atomic_* functions used inside it is also > > > generated > > > as __sync_* calls. > > > > > > libatomic does NOT directly "implement" the basic __atomic_* operations, > > > that's supposed to be done inside the compiler. > > > > > > Can you more specifically describe what you're trying to do? Or is this > > > just > > > a general query? > > > > I don't find any Nios II specific parts in libatomic. > > > > Implementing __atomic_* functions via __sync_* in libatomic makes no sense > > to me. The host specific implementation should provide (libatomic_i.h): > > Most architectures don't have library implementations of __atomic_* > operations, especially if we already have __sync_*. The major difference is > the consistency model arguments in __atomic_* APIs, which is useless for > simpler architectures like nios2. The __sync_* stuff is deprecated.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #7 from Chung-Lin Tang --- (In reply to Sebastian Huber from comment #6) > (In reply to Chung-Lin Tang from comment #5) > > > I checked the code generation on some targets for the test case above. The > > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets > > > generated all __atomic_* functions. > > > > > Only on Nios II it seems, the other targets emit __atomic_* calls. > > > > Many of those target archs use __sync_* by default on Linux, although you > > might generate __atomic_* on bare metal. > > That's the case on nios2; we should be generating __atomic_* calls if you're > > using nios2 ELF (bare metal), for Linux the compiler will generate __sync_* > > calls, unless the architecture has hardware instructions. > > This sounds reasonable. Which magic switch in GCC leads to the generation > of __sync_* functions instead of __atomic_* functions? You can use -fno-sync-libcalls to force OFF __sync_* and generate __atomic_* calls, if that's really what you want (although we have not implemented that kind of runtime support). > > > Implementing __atomic_* functions via __sync_* in libatomic makes no sense > > > to me. The host specific implementation should provide (libatomic_i.h): > > > > Most architectures don't have library implementations of __atomic_* > > operations, especially if we already have __sync_*. The major difference is > > the consistency model arguments in __atomic_* APIs, which is useless for > > simpler architectures like nios2. > > The __sync_* stuff is deprecated. A user can always use the __atomic_* API, the compiler will take care of the rest.
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Created attachment 40047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40047&action=edit untested patch untested patch, generates memcpy for the testcase.
[Bug target/78364] New: [ARM] Error: bit-field extends past end of register -- ubfx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78364 Bug ID: 78364 Summary: [ARM] Error: bit-field extends past end of register -- ubfx Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: arm Since commit r242414, I've noticed that libgcc fails to build for ARM with messages like: /tmp/5778677_3.tmpdir/ccer8XTS.s: Assembler messages: /tmp/5778677_3.tmpdir/ccer8XTS.s:33: Error: bit-field extends past end of register -- `ubfx r0,r0,#25,#8' make[2]: *** [_fractUSQQQ.o] Error 1 make[2]: Leaving directory `/tmp/5778677_3.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc1/arm-none-linux-gnueabihf/lib gcc' make[1]: *** [all-target-libgcc] Error 2 This is --target arm-none-linux-gnueabihf --with-mode=arm --with-cpu=cortex-a9 --with-fpu=vfp but all other combinations I tried have similar issues. As Kyrill said on IRC, it might be a problem similar to PR77822.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #8 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #7)
> (In reply to Sebastian Huber from comment #6)
> > (In reply to Chung-Lin Tang from comment #5)
> > > > I checked the code generation on some targets for the test case above.
> > > > The
> > > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets
> > > > generated all __atomic_* functions.
> > >
> > > > Only on Nios II it seems, the other targets emit __atomic_* calls.
> > >
> > > Many of those target archs use __sync_* by default on Linux, although you
> > > might generate __atomic_* on bare metal.
> > > That's the case on nios2; we should be generating __atomic_* calls if
> > > you're
> > > using nios2 ELF (bare metal), for Linux the compiler will generate
> > > __sync_*
> > > calls, unless the architecture has hardware instructions.
> >
> > This sounds reasonable. Which magic switch in GCC leads to the generation
> > of __sync_* functions instead of __atomic_* functions?
>
> You can use -fno-sync-libcalls to force OFF __sync_* and generate __atomic_*
> calls,
> if that's really what you want (although we have not implemented that kind
> of runtime support).
Ok, thanks for the hint. Now I know where the problem is really. In
"gcc/config/rtems.h" we define TARGET_LINUX_ABI to enable the TLS support for
RTEMS. This is due to (nios2.c):
#undef TARGET_HAVE_TLS
#define TARGET_HAVE_TLS TARGET_LINUX_ABI
We also have:
/* Implement TARGET_INIT_LIBFUNCS. */
static void
nios2_init_libfuncs (void)
{
/* For Linux, we have access to kernel support for atomic operations. */
if (TARGET_LINUX_ABI)
init_sync_libfuncs (UNITS_PER_WORD);
}
Would it be possible to add an alternative way to enable TLS support for RTEMS?
For example:
#ifndef TARGET_HAVE_TLS
#define TARGET_HAVE_TLS TARGET_LINUX_ABI
#endif
Then use in rtems.h:
#define TARGET_HAVE_TLS 1
[Bug c++/78341] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_parser_std_attribute_spec, at cp/parser.c:24597)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78341
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |7.0
--- Comment #2 from Jakub Jelinek ---
Probably just too eager assertion.
24854 cp_parser_parse_tentatively (parser);
24855 alignas_expr = cp_parser_type_id (parser);
24856
24857 if (!cp_parser_parse_definitely (parser))
24858 {
24859 gcc_assert (alignas_expr == error_mark_node
24860 || alignas_expr == NULL_TREE);
alignas_expr is REAL_TYPE double, but it failed to parse anyway due to the
missing '('.
Shall we just remove the assertion?
[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78292 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug middle-end/78333] always-inline gnu-inline functions break -finstrument-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78333 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Richard Biener --- Or a bug of IPA reference / extern inline function body pruning? Maybe instrumentation should set __attribute__((used)) on always-inline functions?
[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114 --- Comment #9 from amker at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #8) > > --- Comment #6 from amker at gcc dot gnu.org --- > > But for tests: > > FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f -O scan-tree-dump-times > > pcom > > "Executing predictive commoning without unrolling" 1 > > FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f -O scan-tree-dump-times > > pcom > > "Predictive commoning failed: no suitable chains" 0 > > > > they happened before 20161011. I tried revision at: > > commit ab93a7014158ec67a0b34e2986742da8a55013f9 > > Author: sje > > Date: Wed Oct 5 18:42:10 2016 + > > > > 2016-10-05 Steve Ellcey > > > > * MAINTAINERS: Update email address after it got reverted. > > > > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240801 > > 138bc75d-0d04-0410-961f-82ee72b054a4 > > > > And it's not working either? > > In my tests (Solaris on various x86 systems, both Intel and AMD), the > failure started consistently between 20161011 (r240990) and 20161013 > (r241136). > > Rainer This case tests if predictive commoning finds out shared memory access between vectorized loop, but it has to check all possible predictive commoning opportunities for all loops, i.e, including prologue and epilogue loops. Unfortunately, vectorizer peels the loop in different ways depending on cost, and on different targets. For example, for solaris x86 toolchain, prologue loop isn't peeled, that's why the newly added test string failed. For haswel, I think it has been failed for long time because there is no predictive commonging opportunity with vf > 2. IMHO, we should refine test only checking predictive commoning for vectorized loop (which is the test means to do), and also skip test for vf!=2. For the latter issue, we maybe able to change test code making it stands for vf>2 cases too. Thanks, bin
[Bug tree-optimization/77673] [5/6/7 Regression] 4-byte load generated instead of 1-byte load, possibly reading past the end of object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77673 --- Comment #3 from Jakub Jelinek --- Regressed with r211778 aka PR61517.
[Bug c/78365] New: ice in determine_value_range, at tree-ssa-loo p-niter.c:413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365 Bug ID: 78365 Summary: ice in determine_value_range, at tree-ssa-loo p-niter.c:413 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 40048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40048&action=edit C source code The attached code, when compiled by gcc trunk dated 20161115, revision 242408, and with compiler flag -O2, does this: mklev.c:80:1: internal compiler error: in determine_value_range, at tree-ssa-loo p-niter.c:413 0xda4cb1 determine_value_range ../../trunk/gcc/tree-ssa-loop-niter.c:413 0xda61f0 bound_difference ../../trunk/gcc/tree-ssa-loop-niter.c:743 0xda61f0 number_of_iterations_cond ../../trunk/gcc/tree-ssa-loop-niter.c:1714 0xda61f0 number_of_iterations_exit_assumptions(loop*, edge_def*, tree_niter_desc *, gcond**, bool) ../../trunk/gcc/tree-ssa-loop-niter.c:2290 0xda7a8b number_of_iterations_exit_assumptions(loop*, edge_def*, tree_niter_desc *, gcond**, bool) I'll have a go at reducing the code and I'll also have a go at trying to find the revision that caused the problem.
[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug debug/78363] [7 Regression] ICE in in force_type_die, at dwarf2out.c:24864
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363 Richard Biener changed: What|Removed |Added Keywords||openmp, wrong-debug CC||jakub at gcc dot gnu.org --- Comment #3 from Richard Biener --- So we emit late debug for we didn't emit early debug for. But we pruned its (type) context already. So the bug is that we fail to emit early debug for the above decl. (gdb) p decl $8 = (gdb) p decl_function_context(decl) $7 = (tree_node *) 0x76a06300 (gdb) p debug_tree ($7) ) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:25227 25227 set_early_dwarf s; Missing separate debuginfos, use: zypper install libgmp10-debuginfo-6.0.0-71.1.x86_64 libisl15-debuginfo-0.16.1-0.x86_64 libmpc3-debuginfo-1.0.2-38.2.x86_64 libmpfr4-debuginfo-3.1.2-3.1.2.x86_64 (gdb) p debug_tree (decl->decl_common.initial) chain > supercontext subblocks supercontext >>> $1 = void (gdb) p debug_tree (0x76a02e40) > so whenever dwarf2out looks at contexts of __lambda0 it ends up at main rather tha at main._omp_fn.0. This is an artifact of move_sese_region_to_fn not copying anything but just "rewiring" stuff. It already replaces BLOCK_VARS by "duplicates" but fails to handle non-vars.
[Bug c++/71988] [7 Regression] ICE in dump_simple_decl (gcc/cp/error.c:965)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71988 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed in r240198.
[Bug fortran/70601] [5/6/7 Regression] [OOP] ICE on procedure pointer component call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70601 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug target/78364] [7 Regression][ARM] Error: bit-field extends past end of register -- ubfx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78364 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||6.2.1 Keywords||assemble-failure Last reconfirmed||2016-11-15 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Summary|[ARM] Error: bit-field |[7 Regression][ARM] Error: |extends past end of |bit-field extends past end |register -- ubfx|of register -- ubfx Target Milestone|--- |7.0 Known to fail||7.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed
[Bug c++/71988] [7 Regression] ICE in dump_simple_decl (gcc/cp/error.c:965)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71988 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Nov 15 15:21:49 2016 New Revision: 242426 URL: https://gcc.gnu.org/viewcvs?rev=242426&root=gcc&view=rev Log: PR c++/71988 * g++.dg/cpp0x/constexpr-71988.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-71988.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/78365] ice in determine_value_range, at tree-ssa-loo p-niter.c:413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365 --- Comment #1 from David Binderman --- Created attachment 40049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40049&action=edit reduced C source code
[Bug other/78366] New: target_clones does not generate resovler function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366
Bug ID: 78366
Summary: target_clones does not generate resovler function
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The doc to target_clones says
# For instance, on an x86, you could compile a function with
# `target_clones("sse4.1,avx")'. GCC creates two function clones,
# one compiled with `-msse4.1' and another with `-mavx'. It also
# creates a resolver function (see the `ifunc' attribute above) that
# dynamically selects a clone suitable for current architecture.
Gcc creates the three functions all right, but it does not create the
resolver function; or at least I am unable to find it in the assembly
code.
double foo(double *, double *, int) __attribute__
((target_clones("avx,default")));
double foo(double *a, double *b, int n)
{
double s;
int i;
s = 0.0;
for (i=0; i gcc -O -S target.c
ig25@linux-fd1f:~/Krempel/Target> cat target.s
.file "target.c"
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
testl %edx, %edx
jle .L4
leal-1(%rdx), %edx
addq$1, %rdx
movl$0, %eax
pxor%xmm0, %xmm0
.L3:
movsd (%rdi,%rax,8), %xmm1
addsd (%rsi,%rax,8), %xmm1
addsd %xmm1, %xmm0
addq$1, %rax
cmpq%rdx, %rax
jne .L3
rep ret
.L4:
pxor%xmm0, %xmm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.type foo.avx.0, @function
foo.avx.0:
.LFB1:
.cfi_startproc
testl %edx, %edx
jle .L9
leal-1(%rdx), %edx
addq$1, %rdx
movl$0, %eax
vxorpd %xmm0, %xmm0, %xmm0
.L8:
vmovsd (%rdi,%rax,8), %xmm1
vaddsd (%rsi,%rax,8), %xmm1, %xmm1
vaddsd %xmm1, %xmm0, %xmm0
addq$1, %rax
cmpq%rdx, %rax
jne .L8
rep ret
.L9:
vxorpd %xmm0, %xmm0, %xmm0
ret
.cfi_endproc
.LFE1:
.size foo.avx.0, .-foo.avx.0
.ident "GCC: (GNU) 7.0.0 20161112 (experimental)"
.section.note.GNU-stack,"",@progbits
[Bug target/78364] [7 Regression][ARM] Error: bit-field extends past end of register -- ubfx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78364
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot
gnu.org
--- Comment #2 from ktkachov at gcc dot gnu.org ---
The bad assembly comes from the extzv_t2 pattern which ends up accepting:
24 @(insn:TI 12 6 13 (set (reg:SI 0 r0)
25 @(zero_extract:SI (reg:SI 0 r0 [ a ])
26 @(const_int 16 [0x10])
27 @(const_int 17 [0x11]))) {extzv_t2}
28 @ (nil))
So the predicates need to be tightened
[Bug c++/78349] function returning std::basic_string missing [abi:cxx11] tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78349 --- Comment #1 from Jonathan Wakely --- I think this is a known issue and intentionally not fixed on the GCC 5 branch (but it is fixed for GCC 6). N.B. GNU nm has a -C option to demangle so you don't need c++filt.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #9 from Chung-Lin Tang ---
(In reply to Sebastian Huber from comment #8)
> (In reply to Chung-Lin Tang from comment #7)
> > (In reply to Sebastian Huber from comment #6)
> > > (In reply to Chung-Lin Tang from comment #5)
> > > > > I checked the code generation on some targets for the test case
> > > > > above. The
> > > > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets
> > > > > generated all __atomic_* functions.
> > > >
> > > > > Only on Nios II it seems, the other targets emit __atomic_* calls.
> > > >
> > > > Many of those target archs use __sync_* by default on Linux, although
> > > > you
> > > > might generate __atomic_* on bare metal.
> > > > That's the case on nios2; we should be generating __atomic_* calls if
> > > > you're
> > > > using nios2 ELF (bare metal), for Linux the compiler will generate
> > > > __sync_*
> > > > calls, unless the architecture has hardware instructions.
> > >
> > > This sounds reasonable. Which magic switch in GCC leads to the generation
> > > of __sync_* functions instead of __atomic_* functions?
> >
> > You can use -fno-sync-libcalls to force OFF __sync_* and generate __atomic_*
> > calls,
> > if that's really what you want (although we have not implemented that kind
> > of runtime support).
>
> Ok, thanks for the hint. Now I know where the problem is really. In
> "gcc/config/rtems.h" we define TARGET_LINUX_ABI to enable the TLS support
> for RTEMS. This is due to (nios2.c):
>
> #undef TARGET_HAVE_TLS
> #define TARGET_HAVE_TLS TARGET_LINUX_ABI
>
> We also have:
>
> /* Implement TARGET_INIT_LIBFUNCS. */
> static void
> nios2_init_libfuncs (void)
> {
> /* For Linux, we have access to kernel support for atomic operations. */
> if (TARGET_LINUX_ABI)
> init_sync_libfuncs (UNITS_PER_WORD);
> }
>
> Would it be possible to add an alternative way to enable TLS support for
> RTEMS? For example:
>
> #ifndef TARGET_HAVE_TLS
> #define TARGET_HAVE_TLS TARGET_LINUX_ABI
> #endif
>
> Then use in rtems.h:
>
> #define TARGET_HAVE_TLS 1
I think I know what you need, I submit a patch later.
[Bug libstdc++/78361] [7 regression][c++1z] std::__is_referenceable doesn't handle noexcept function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78361 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-15 Component|c++ |libstdc++ Ever confirmed|0 |1
[Bug libstdc++/78326] incorrect c++ usage in experimental/vector and others? _X_max_align is inaccessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78326 --- Comment #6 from Jonathan Wakely --- See Bug 59002, this is one of the ones it depends on.
[Bug fortran/66227] [5/6/7 Regression] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|[OOP] EXTENDS_TYPE_OF n |[5/6/7 Regression] [OOP] |returns wrong result for|EXTENDS_TYPE_OF n returns |polymorphic variable|wrong result for |allocated to extended type |polymorphic variable ||allocated to extended type --- Comment #3 from janus at gcc dot gnu.org --- Confirmed. What's funny is that all eight cases are simplified to compile-time constants. That clearly shouldn't be. Probably there's a bug in gfc_simplify_extends_type_of. I think this is a (very old) regression caused by PR 41850: gfortran 4.5 gets all the values right!
[Bug c++/78313] [7 Regression] Misleading spelling suggestion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78313
--- Comment #3 from David Malcolm ---
(In reply to Jakub Jelinek from comment #0)
> +++ This bug was initially created as a clone of Bug #72774 +++
>
> // PR c++/72774
> // { dg-do compile }
>
> void baz ();
> namespace A { void foo (); }
> void bar ()
> {
> using A::foo;
> 0 ? static_cast (0) : baz; // { dg-error "does not name a type" }
> }
>
> Actually, the suggestion looks wrong:
>
> pr72774.C:9:19: error: ‘foo’ does not name a type; did you mean ‘foo’?
>
> We call lookup_name_fuzzy with kind that we want a typename, but we actually
> except for members consider even FUNCTION_DECLs/VAR_DECLs. That doesn't
> look right.
I tried fixing this with:
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 84e064d..f0205a6 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -4723,11 +4723,12 @@ consider_binding_level (tree name, best_match &bm,
cp_binding_level *lvl, bool look_within_fields,
enum lookup_name_fuzzy_kind kind)
{
+ bool want_type_p = (kind == FUZZY_LOOKUP_TYPENAME);
+
if (look_within_fields)
if (lvl->this_entity && TREE_CODE (lvl->this_entity) == RECORD_TYPE)
{
tree type = lvl->this_entity;
- bool want_type_p = (kind == FUZZY_LOOKUP_TYPENAME);
tree best_matching_field
= lookup_member_fuzzy (type, name, want_type_p);
if (best_matching_field)
@@ -4757,6 +4758,11 @@ consider_binding_level (tree name, best_match &bm,
&& DECL_ANTICIPATED (d))
continue;
+ /* Function decls are not types. */
+ if (TREE_CODE (d) == FUNCTION_DECL
+ && want_type_p)
+ continue;
+
if (DECL_NAME (d))
bm.consider (DECL_NAME (d));
}
but then I get this:
error: 'foo' does not name a type; did you mean 'bool'?
It seems better to simply not offer a suggestion for this case (I have a patch
to do this, by detecting suggestion==goal, and suppressing such a suggestion)
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 --- Comment #6 from Andrew Benson --- (In reply to janus from comment #3) > (In reply to janus from comment #2) > > I suspect it may be caused by Andre's r241885 ... > > I may be wrong, though: It seems like reverting those changes does not solve > the problem. > > Another candidate: r241439. > > > @Andrew: Are you aware of an earlier trunk build where this was still > working? If yes, can you give a revision number? I didn't record the previous revision number I used unfortunately, but it looks like you were able to figure out the problem revision anyway,
[Bug c++/78367] New: Out-of-line definitions fail to match in-line declarations with decltype and template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78367
Bug ID: 78367
Summary: Out-of-line definitions fail to match in-line
declarations with decltype and template arguments
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at qult dot net
Target Milestone: ---
The following code doesn't compile with -std=gnu++11 in any of GCC 4.9.4, 5.4.1
or 6.2.0:
#include
struct Bar {
void meth(int) {}
};
struct Foo {
template
decltype(std::declval().meth(std::declval()))
call_meth(T v);
};
template
decltype(std::declval().meth(std::declval()))
Foo::call_meth(T v)
{ return Bar{}.meth(v); }
The compile complains that the out-of-line definition doesn't match the in-line
declaration.
This code compiles with Clang.
[Bug c/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-15 CC||kuganv at linaro dot org, ||marxin at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ice in |[7 Regression] ICE in |determine_value_range, at |determine_value_range, at |tree-ssa-loo p-niter.c:413 |tree-ssa-loo p-niter.c:413 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Started with r240292.
[Bug fortran/66227] [5/6/7 Regression] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > Confirmed. What's funny is that all eight cases are simplified to > compile-time constants. That clearly shouldn't be. Probably there's a bug in > gfc_simplify_extends_type_of. The regression is due to r168579. The following patch fixes it: Index: simplify.c === --- simplify.c (Revision 242412) +++ simplify.c (Arbeitskopie) @@ -2531,11 +2531,7 @@ mold->ts.u.derived->components->ts.u.derived) && !gfc_type_is_extension_of (mold->ts.u.derived->components->ts.u.derived, -a->ts.u.derived)) - || (a->ts.type == BT_CLASS && mold->ts.type == BT_DERIVED - && !gfc_type_is_extension_of - (mold->ts.u.derived, -a->ts.u.derived->components->ts.u.derived))) +a->ts.u.derived))) return gfc_get_logical_expr (gfc_default_logical_kind, &a->where, false); if (mold->ts.type == BT_DERIVED
[Bug fortran/66227] [5/6/7 Regression] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) > The following patch fixes it: ... but unfortunately causes a failure of extends_type_of_3.f90 in the testsuite, which means either: * one of the tests in extends_type_of_3.f90 is wrong or * we're missing an optimization opportunity with my patch. I'm currently not sure which one it is, but I'll investigate.
[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 --- Comment #5 from Jason Merrill --- Author: jason Date: Tue Nov 15 16:32:38 2016 New Revision: 242432 URL: https://gcc.gnu.org/viewcvs?rev=242432&root=gcc&view=rev Log: PR c++/78358 - tuple decomposition decltype * semantics.c (finish_decltype_type): Strip references for a tuple decomposition. * cp-tree.h (DECL_DECOMPOSITION_P): False for non-variables. Added: trunk/gcc/testsuite/g++.dg/cpp1z/decomp12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/semantics.c
[Bug tree-optimization/70965] [7 Regression] ICE on released SSA name during IPA SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70965 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Started with r235817. Will try to reduce.
[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356 --- Comment #7 from vehre at gcc dot gnu.org --- Fix at: https://gcc.gnu.org/ml/fortran/2016-11/msg00140.html
[Bug target/78362] [7 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1804 during libgomp build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78362 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Testing a patch.
[Bug c++/78341] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_parser_std_attribute_spec, at cp/parser.c:24597)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78341 --- Comment #3 from Jason Merrill --- (In reply to Jakub Jelinek from comment #2) > Shall we just remove the assertion? Sounds good.
