Re: volatile access optimization (C++ / x86_64)
On Fri, 2014-12-26 at 23:19 +, Andrew Haley wrote: On 26/12/14 22:49, Matt Godbolt wrote: At the moment I think the best I can do is to use an inline assembly version of the increment which prevents GCC from doing any optimisation upon it. That seems rather ugly though, and if anyone has any better suggestions I'd be very grateful. Well, that's the problem: do you want a barrier or not? With no barrier there is no guarantee that the data will ever be written to memory. Do you only care about x86 processors? The C++11 memory model guarantees the following though (1.10p25): An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads in a finite period of time.
Re: volatile access optimization (C++ / x86_64)
On Fri, 2014-12-26 at 22:26 +, Andrew Haley wrote: On 26/12/14 20:32, Matt Godbolt wrote: I'm investigating ways to have single-threaded writers write to memory areas which are then (very infrequently) read from another thread for monitoring purposes. Things like number of units of work done. I initially modeled this with relaxed atomic operations. This generates a lock xadd style instruction, as I can't convey that there are no other writers. As best I can tell, there's no memory order I can use to explain my usage characteristics. Giving up on the atomics, I tried volatiles. These are less than ideal as their power is less expressive, but in my instance I am not trying to fight the ISA's reordering; just prevent the compiler from eliding updates to my shared metrics. GCC's code generation uses a load; add; store for volatiles, instead of a single add 1, [metric]. This is correct. http://goo.gl/dVzRSq has the example (which is also at the bottom of my email). Is there a reason why (in principal) the volatile increment can't be made into a single add? Clang and ICC both emit the same code for the volatile and non-volatile case. Yes. Volatiles use the as if rule, where every memory access is as written. a volatile increment is defined as a load, an increment, and a store. If you want single atomic increment, atomics are what you should use. If you want an increment to be written to memory, use a store barrier after the increment. I agree with Andrew. My understanding of volatile is that the generated code must do exactly what the abstract machine would do. One can use volatiles for synchronization if one is also manually adding HW barriers and potentially compiler barriers (depending on whether you need to mix volatile and non-volatile) -- but volatiles really aim at a different use case than atomics. For the single-writer shared-counter case, a load and a store operation with memory_order_relaxed seem to be right approach.
Re: 404 @ https://gcc.gnu.org/gcc-5/
On 29-12-2014 18:36, Jonathan Wakely wrote: On 29 December 2014 at 15:34, Ed Smith-Rowland wrote: The note on C++14 conformance referred to is not the place for this but: is our C++11 support really less tested and more experimental than our C++03 support at this point? One thing I can think of might be gcc bootstrap. The main difference is ABI stability, which is not guaranteed for C++11 (but should be once the std::string changes and resulting churn settle down). Is std::string still being fixed? Will that fix be part of 5.0? Are ABI concerns holding back other things as well? Olaf
Re: 404 @ https://gcc.gnu.org/gcc-5/
On 29-12-2014 16:34, Ed Smith-Rowland wrote: The note about C++14 conformance is great as it stands modulo link errors. Why is it great to not mention the experimental qualifier? Do all files / libraries have to be compiled with the same -std option? If so, this option causes ABI issues by itself. Olaf
Re: 404 @ https://gcc.gnu.org/gcc-5/
On 12/30/2014 07:50 AM, Olaf van der Spek wrote: On 29-12-2014 16:34, Ed Smith-Rowland wrote: The note about C++14 conformance is great as it stands modulo link errors. Why is it great to not mention the experimental qualifier? Do all files / libraries have to be compiled with the same -std option? If so, this option causes ABI issues by itself. Olaf I should have replaced 'conformance' with 'feature completeness' in my sentences. The words in the message indicate 'features'. The word experimental appears in bold. My understanding is that the C++11 ABI changes to string, list, ios_base::failure (are there others?) that have been queued for a while have been put into gcc5. This is the big release. There was a message https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01669.html (and subsequent) on this. Check https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00268.html for std::list. Check https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01750.html for std::ios_base::failure. I'm quite sure that once the ABI issues have been stabilized appropriate formal announcements and documentation will appear on this subject. Ed
Re: 404 @ https://gcc.gnu.org/gcc-5/
On 30 December 2014 at 15:29, Ed Smith-Rowland wrote: On 12/30/2014 07:50 AM, Olaf van der Spek wrote: On 29-12-2014 16:34, Ed Smith-Rowland wrote: The note about C++14 conformance is great as it stands modulo link errors. Why is it great to not mention the experimental qualifier? The point of the announcement is not to repeat all the information that is already provided elsewhere (specifically on the page the announcement links to), and since the experimental status didn't change there's nothing to announce w.r.t that status. I think you're just being picky - does it really matter? Do all files / libraries have to be compiled with the same -std option? No. That has never been necessary. If so, this option causes ABI issues by itself. Olaf I should have replaced 'conformance' with 'feature completeness' in my sentences. The words in the message indicate 'features'. The word experimental appears in bold. My understanding is that the C++11 ABI changes to string, list, ios_base::failure (are there others?) that have been queued for a while have been put into gcc5. This is the big release. There was a message https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01669.html (and subsequent) on this. Check https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00268.html for std::list. Check https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01750.html for std::ios_base::failure. I'm quite sure that once the ABI issues have been stabilized appropriate formal announcements and documentation will appear on this subject. Exactly. It would be premature to announce them while I'm still fixing the fall-out. I still don't understand what a C++14 announcement has to do with the status of C++11. The entire thread seems to boil down to I'm not happy with an announcement of X, why doesn't it also make an announcement of Y? so I'm going to stop wasting my time in this thread.
Re: volatile access optimization (C++ / x86_64)
On Dec 30, 2014, at 1:32 PM, Matt Godbolt m...@godbolt.org wrote: On Tue, Dec 30, 2014 at 5:05 AM, Torvald Riegel trie...@redhat.com wrote: I agree with Andrew. My understanding of volatile is that the generated code must do exactly what the abstract machine would do. That makes sense. I suppose I don't understand what the difference is in terms of an abstract machine of load; add; store versus the load-add-store. At least from on x86, from the perspective of the memory bus, there's no difference I'm aware of. That was my point. The model needs to treat those two as equivalent, otherwise the model is constructed by theories that I don’t understand. paul
Re: How to upgrade a tool-chain tree...
On 12/28/2014 02:27 PM, Alan Lehotsky wrote: I have a tool chain for an experimental processor, built starting with release or snapshot distributions of binutils-2.21 cgen-20110901 gcc-4.6.1 newlib-1.19.0 gdb 7.2 I'm using SVN for version control locally. I'd like to upgrade it to a newer source base; but since it wasn't done by checking out from the FSF and Sourceware version-control systems, I'm wondering if there's any clever way to merge my tree or if I just have to bite the bullet and essentially take everything I've modified since version 1 in my source tree and import them into a new source tree? Hi Alan, I'm doing a similar thing with multiple packages for my project. I currently have the following versions of the packages I use http://ellcc.org/blog/?page_id=467 I keep all the packages in a vendor branch of my svn repository http://ellcc.org/viewvc/svn/vendor/ I use svn_load_dirs.pl to bring in a new release or snapshot with a command like this: /usr/share/doc/subversion-1.6.18/svn_load_dirs.pl -svn_username rich -svn_password XX -t binutils-new version http://ellcc.org/svn/vendor/binutils current binutils Then I use svn merge --accept edit http://ellcc.org/svn/vendor/binutils/binutils-old version http://ellcc.org/svn/vendor/binutils/current binutils to merge the new source updates into my source tree. I do the updates frequently, or at least as often as new releases happen. Especially the clang/LLVM part, which I update weekly because it changes so fast. Usually the merges go smoothly but sometimes I have to manually arbitrate between merge conflicts. I'm not sure if this will help you update your current sources since you may not have a tag on the original sources you brought in. I found this technique a while ago via google. There are probably better ways to do this, bit it works for me. -Rich
Typo ?
Hello, in 'https://gcc.gnu.org/gcc-4.9/changes.html' there is a reference to '-Wzerotrips' Is this not '-Wzerotrip' without 's' ? Cheers, Francois-Xavier
[Bug libstdc++/64441] New: A match_results returns an incorrect sub_match if the sub_match::matched is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
Bug ID: 64441
Summary: A match_results returns an incorrect sub_match if the
sub_match::matched is false
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34362
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34362action=edit
g++ -v
Please see the following sample.
== sample code
==
#include iostream
#include regex
int main()
{
const char s[] = abc;
const std::regex re((\\d+)|(\\w+));
std::cmatch m;
std::regex_search(s, m, re);
std::cout std::boolalpha;
for (size_t i = 0, n = m.size(); i n; ++i) {
auto sub = m[i];
std::cout i : sub.matched , str = ' sub.str() ',
range = [ sub.first - s , sub.second - s )
std::endl;
}
}
=
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [-140734305427376, -140734305427376)
2:true, str = 'abc', range = [0, 3)
==
cf. http://melpon.org/wandbox/permlink/SBoMF5UKYYa38Y4N
The C++11 standard 28.10[re.results]/p.4 says, Otherwise matched is false, and
members first and second point to the end of the sequence that was searched.
So, I think that the output should be
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [3, 3)
2:true, str = 'abc', range = [0, 3)
==
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- also in cp2k we use separate calls for getting the count_rate, count_max and count. I think as long as they are the same kind there should be no problem. *8 arguments resolve to the _8 version and *4 to the _4 version. Both versions ideally have different resolution. I would argue that allowing a single call to system_clock to have integer arguments of different kind is somewhat of a bug in the standard, possibly worthy of a compiler warning. In that case, I would resolve return -HUGE,0,0 i.e. system_clock of this version not supported (also allowed by the standard). Actually, the latter seems like a good idea for integer*1 and integer*2 system_clock calls as well, since the current version is non-conforming. cat test.f90 INTEGER*1 :: count,count_max,count_rate DO CALL SYSTEM_CLOCK(count,count_max,count_rate) write(6,*) count,count_max,count_rate ENDDO END ./a.out | head -14 -24 -1 -13 -24 -1
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- reading the standard, indeed it seems like count_rate can be real as well... same rules here *4 - _4 *8 - _8. As a side remark the following generates a slightly outdated error: cat test.f90 COMPLEX(KIND=4) :: count_rate CALL SYSTEM_CLOCK(count_rate=count_rate) END gfortran test.f90 test.f90:2:29: CALL SYSTEM_CLOCK(count_rate=count_rate) 1 Error: ‘count_rate’ argument of ‘system_clock’ intrinsic at (1) must be INTEGER should be 'INTEGER or REAL'. count and count_max are still integer.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #11 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 34363 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34363action=edit patch to fix issue This patch fixed almost all issues related to operand canonicalization.
[Bug c/64442] New: -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
Bug ID: 64442
Summary: -O1 modify output of a simple computation with
rounding
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colin.pitrat+gcc at gmail dot com
When building the following program with -O1, it outputs 85 whereas without -O1
it outputs 84:
#include stdio.h
#include stdint.h
int main()
{
double max = 8.03;
double a = 6.01;
double b = 5;
double c = (double)0xFF / (max - b);
int16_t value = (a - b) * c;
printf(Result = %d\n, value);
return 0;
}
The compilation lines I use are really minimal:
- gcc main.c
vs
- gcc -O1 main.c
I tried to find which optimization flag was producing this issue but couldn't
find any !
- I don't have the issue when I don't use -O1 but provide explicitely all (or
any of) -O1 optimization flags (obtained with gcc -Q -O1 --help=optimizers |
grep \-f | grep enabled | awk '{ print $1 }' | xargs)
- Among all optimizer flags, I have the same issue only when providing either
-fsingle-precision-constant, -ffloat-store or -fshort-double but those flags
are supposed to be deactivated in -O1
Note that I didn't test -fpack-struct because it didn't build
Regards,
Colin
[Bug c/64440] -Wdiv-by-zero false negative on const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Chengnian Sun from comment #2) Thanks for your reply. It seems GCC sometimes does consider const int for other types of warnings (but not for -Wdiv-by-zero). See the following, with -O3, GCC warns that the left shift count is negative. I wonder how this happens? The warning is still given by the FE! Nonetheless, clang is able to warn without optimization because it has some constant propagation pass in the FE. GCC does not have such a thing and current developers are not convinced that it is worth it. I think there are several PRs open about this, and it doesn't seem useful to have one PR for each possible warning that could be improved by this.
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- Are you compiling on 32-bit x86? I can reproduce on m68k, but not on x86_64 (even with -m32) or on ARMv5. I suspect you're seeing the effects of excess precision of the x87 FPU (much like the m68k FPU).
[Bug bootstrap/50139] in-tree GMP/PPL/CLooG is misconfigured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to nightstrike from comment #3) There's other relevant posts, but you get the idea. Anyway, this should eventually be closed. So be it. Thanks for noticing. (You can probably get a gcc.gnu.org bugzilla account, if you wish so).
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 Bug 50156 depends on bug 50139, which changed state. Bug 50139 Summary: in-tree GMP/PPL/CLooG is misconfigured https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- CLooG will be removed in GCC 5.0. If you still think these patches are useful for trunk please re-open the bug. Patches in bugzilla tend to get lost, it is better to send them to gcc-patches@ and ping, ping, ping, ping... until you get someone to review them.
[Bug libstdc++/64443] New: New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 Bug ID: 64443 Summary: New std::string implementation breaks tests on AArch64. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org This commit seems to be breaking libstdc++-v3 runs on AArch64. Author: redi redi@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Dec 19 18:16:39 2014 + New std::string implementation. * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_CXX11_ABI): Remove. (GLIBCXX_ENABLE_LIBSTDCXX_DUAL_ABI, GLIBCXX_DEFAULT_ABI): Add. * configure.ac: Use new macros. * configure: Regenerate. * Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * include/Makefile.am: Set _GLIBCXX_USE_DUAL_ABI. * include/Makefile.in: Regenerate. * config/abi/pre/gnu.ver: Export symbols related to new std::string. Tighten old patterns to not match new symbols. * config/locale/generic/monetary_members.cc: Guard some definitions to not compile with new ABI. * config/locale/gnu/monetary_members.cc: Likewise. * config/locale/gnu/numeric_members.cc: Prevent double-free. PASS-FAIL: 22_locale/locale/cons/6.cc execution test PASS-FAIL: 22_locale/num_get/get/char/11.cc execution test PASS-FAIL: 22_locale/num_get/get/char/12.cc execution test PASS-FAIL: 22_locale/num_get/get/char/13.cc execution test PASS-FAIL: 22_locale/num_get/get/char/14.cc execution test PASS-FAIL: 22_locale/num_get/get/char/15.cc execution test PASS-FAIL: 22_locale/num_get/get/char/22131.cc execution test PASS-FAIL: 22_locale/num_get/get/char/23953.cc execution test PASS-FAIL: 22_locale/num_get/get/char/37958.cc execution test PASS-FAIL: 22_locale/num_get/get/char/39168.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/11.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/12.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/13.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/14.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/15.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/22131.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/23953.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/37958.cc execution test PASS-FAIL: 22_locale/num_get/get/wchar_t/39168.cc execution test PASS-FAIL: 22_locale/num_put/put/char/11.cc execution test PASS-FAIL: 22_locale/num_put/put/char/23953.cc execution test PASS-FAIL: 22_locale/num_put/put/char/38196.cc execution test PASS-FAIL: 22_locale/num_put/put/wchar_t/11.cc execution test PASS-FAIL: 22_locale/num_put/put/wchar_t/23953.cc execution test PASS-FAIL: 22_locale/num_put/put/wchar_t/38196.cc execution test PASS-FAIL: 22_locale/numpunct/members/char/cache_1.cc execution test PASS-FAIL: 22_locale/numpunct/members/char/cache_2.cc execution test PASS-FAIL: 22_locale/numpunct/members/wchar_t/cache_1.cc execution test PASS-FAIL: 22_locale/numpunct/members/wchar_t/cache_2.cc execution test
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Component|target |middle-end
--- Comment #13 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to H.J. Lu from comment #12)
Created attachment 34361 [details]
A new patch
Please try the new patch.
No, this approach is wrong. ix86_fixup_binary_operands should not be used to
legitimize PIC address. The -fpic expansion is already wrong, since it
produces:
;; ivtmp.9_4 = (unsigned long) _37;
(insn 59 58 0 (parallel [
(set (reg:DI 123 [ ivtmp.9 ])
(plus:DI (reg:DI 124 [ D.3980 ])
(symbol_ref:DI (G) var_decl 0x7f8c6facc900 G)))
(clobber (reg:CC 17 flags))
]) -1
(nil))
This is similar to:
--cut here--
typedef __SIZE_TYPE__ size_t;
extern char G[8];
char *a (size_t z)
{
return G[z];
}
--cut here--
Without -fpic, the compiler expands to:
6: {r90:DI=r89:DI+`G';clobber flags:CC;}
Compare this with -fpic expansion:
6: r92:DI=[const(unspec[`G'] 2)]
7: r91:DI=r92:DI
REG_EQUAL `G'
8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
Looking at the above, it looks the problem is in the middle-end, where symbol
address should be legitimized through ix86_legitimize_address (a.k.a
TARGET_LEGITIMIZE_ADDRESS).
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 --- Comment #2 from Colin Pitrat colin.pitrat+gcc at gmail dot com --- Yes I'm building on i686. But I thought -O1 and -O2 were safe optimization that weren't supposed to change the behaviour. Moreover, I'm surprised that providing the list of -f flags -O1 is supposed to enable doesn't allow me to reproduce the issue.
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Uroš Bizjak from comment #13)
(In reply to H.J. Lu from comment #12)
Created attachment 34361 [details]
A new patch
Please try the new patch.
No, this approach is wrong. ix86_fixup_binary_operands should not be used to
legitimize PIC address. The -fpic expansion is already wrong, since it
produces:
--cut here--
typedef __SIZE_TYPE__ size_t;
extern char G[8];
char *a (size_t z)
{
return G[z];
}
--cut here--
Without -fpic, the compiler expands to:
6: {r90:DI=r89:DI+`G';clobber flags:CC;}
Compare this with -fpic expansion:
6: r92:DI=[const(unspec[`G'] 2)]
7: r91:DI=r92:DI
REG_EQUAL `G'
8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
This is generated in the backend:
Starting program: /export/build/gnu/gcc/build-x86_64-linux/gcc/cc1
-fpreprocessed /tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=x86-64
-auxbase x -version -fPIC -o x.s
GNU C11 (GCC) version 5.0.0 20141228 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 5.0.0 20141228 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e92c7e019abbedeeeac36edef3dbfdca
Breakpoint 6, legitimize_pic_address (orig=0x719c8840, reg=0x0)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:13565
13565 rtx addr = orig;
(gdb) bt
#0 legitimize_pic_address (orig=0x719c8840, reg=0x0)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:13565
#1 0x01082cf2 in ix86_expand_move (mode=DImode,
operands=0x7fffc840)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:17311
#2 0x011a2c3f in gen_movdi (operand0=0x719c88b8,
operand1=0x719c8840)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.md:1938
#3 0x0084471f in insn_gen_fn::operator() (
this=0x1a82330 insn_data+201136, a0=0x719c88b8, a1=0x719c8840)
at /export/gnu/import/git/gcc/gcc/recog.h:303
#4 0x0091cb20 in emit_move_insn_1 (x=0x719c88b8, y=0x719c8840)
at /export/gnu/import/git/gcc/gcc/expr.c:3529
#5 0x0091cf74 in emit_move_insn (x=0x719c88b8, y=0x719c8840)
at /export/gnu/import/git/gcc/gcc/expr.c:3624
...
(gdb) call debug_rtx (orig)
(symbol_ref:DI (G) [flags 0x40] var_decl 0x7189e900 G)
(gdb)
[Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This commit seems to be breaking libstdc++-v3 runs on AArch64. Is this under Linux or with newlib?
[Bug ipa/64444] New: [5 Regression] ICE: in inline_merge_summary, at ipa-inline-analysis.c:3611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Bug ID: 6
Summary: [5 Regression] ICE: in inline_merge_summary, at
ipa-inline-analysis.c:3611
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Happens during Firefox LTO build on ppc64:
trippels@gcc2-power8 genrb % parse.ii
int *k_type_string;
struct
{
int *nameUChars;
} gResourceTypes{ k_type_string };
trippels@gcc2-power8 genrb % ucol_tok.ii
typedef struct
{
int charsOffset;
} UColParsedToken;
typedef struct
{
UColParsedToken parsedToken;
int source;
int *extraCurrent;
int inRange;
} UColTokenParser;
typedef struct
{
int *subName;
} ucolTokSuboption;
int *suboption_00;
ucolTokSuboption alternateSub{ suboption_00 };
static int
fn1 (UColTokenParser *p1)
{
p1-parsedToken.charsOffset = p1-extraCurrent - p1-source;
}
void
fn2 (UColTokenParser *p1)
{
if (p1-inRange)
fn1 (p1);
}
trippels@gcc2-power8 genrb % c++ -r -nostdlib -O2 -flto -std=gnu++0x parse.ii
ucol_tok.ii
lto1: internal compiler error: in inline_merge_summary, at
ipa-inline-analysis.c:3611
0x10490b63 inline_merge_summary(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3611
0x10d0fa4b inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*,
int*, bool, bool*)
../../gcc/gcc/ipa-inline-transform.c:326
0x10d07b1b inline_small_functions
../../gcc/gcc/ipa-inline.c:1813
0x10d07b1b ipa_inline
../../gcc/gcc/ipa-inline.c:2185
0x10d07b1b execute
../../gcc/gcc/ipa-inline.c:2558
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.
lto-wrapper: fatal error: /home/trippels/gcc_test/usr/local/bin/c++ returned 1
exit status
compilation terminated.
/home/trippels/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug ipa/64444] [5 Regression] ICE: in inline_merge_summary, at ipa-inline-analysis.c:3611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r219108.
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #15 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to H.J. Lu from comment #14) This is generated in the backend: Yes, but the question is, why somehow similar testcase legitimizes the address correctly with -fpic, while the original testcase doesn't.
[Bug c++/64445] New: virtual functions polymorphism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64445 Bug ID: 64445 Summary: virtual functions polymorphism Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nagl46 at web dot de Created attachment 34364 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34364action=edit example of described bug A base class base has two virtual functions virtual void Y( float xx ); virtual void Y( int xx); A new class ext that inherits from base class re-implements the function virtual void Y( float xx ); Calling function Y(float) on a pointer base * pointing to an ext instance results in a call to base::Y(int). I would expect a call to the ext::Y(float) function. Is it a bug or is it my mistake? It's the same behavior in gcc 4.7.2 and gcc 5.0.0.
[Bug c++/64445] virtual functions polymorphism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64445 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- int xx = 0; anExt.Y(xx); // calls Y(float) since Y(int) is hidden by ext::Y(float) aBaseP-Y(xx); // calls Y(int) since int is a direct match inside base.
[Bug c++/64446] New: Misleading error message when inheriting from a template class w/o the template params
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64446
Bug ID: 64446
Summary: Misleading error message when inheriting from a
template class w/o the template params
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
When compiling the under code, g++ gives a misleading error message:
$ g++-5.0.0 -Wall 20141230-templ_base.cpp
20141230-templ_base.cpp:7:1: error: expected class-name before ‘{’ token
'Base' is definitely a valid class name.
The problem is that the name given is a class, but it's a template and the
template argument is missing.
However, in the second case, when inheriting from Base2 and only one template
argument is given of the two, the error message is OK: wrong number of template
arguments (1, should be 2).
Something similar would be desirable in the first case, not to waste time
staring at the screen, searching for a typo in the class name and finding none.
Like 'classname is a template but no template arguments are given'.
$ g++-5.0.0 -v
Using built-in specs.
COLLECT_GCC=g++-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.0.0
Thread model: posix
gcc version 5.0.0 20141222 (experimental) (GCC)
4.9 and 4.8 gives the same misleading error message.
8888
templatetypename T
struct Base
{
};
struct Foo : Base
{ // error: expected class-name before ‘{’ token
};
templatetypename T, typename U
struct Base2
{
};
struct Foo2 : Base2int // OK: wrong number of template arguments (1, should
be 2)
{
};
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 --- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com --- See PR323 and https://gcc.gnu.org/bugs/#known You could experiment with -ffloat-store, -mpc64, or -msse2 (if your CPU supports SSE2, which it should if it isn't ancient).
[Bug c++/64446] Misleading error message when inheriting from a template class w/o the template params
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64446
--- Comment #1 from petschy at gmail dot com ---
One subtlety:
templatetypename T=void
struct Base3
{
};
struct Foo3 : Base3
{
};
In this case complaining about missing template params is probably
inappropriate, since Base3 is perfectly valid.
So on second thought, the error should be about the missing after the class
name.
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #16 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Uroš Bizjak from comment #15)
(In reply to H.J. Lu from comment #14)
This is generated in the backend:
Yes, but the question is, why somehow similar testcase legitimizes the
address correctly with -fpic, while the original testcase doesn't.
My impressions are most of PIC addresses like:
6: r92:DI=[const(unspec[`G'] 2)]
7: r91:DI=r92:DI
REG_EQUAL `G'
8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
is generated by x86 backend vi ix86_expand_move and x86 backend was never
presented with other opportunities before. X86 backend isn't prepared to
handle some RTL expansions from offload.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin and others after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Apologies, I should read emails more carefully when I'm ill, or not respond at all! I plan to spend time on this later this week. HNY all!
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #17 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to H.J. Lu from comment #16)
This is generated in the backend:
Yes, but the question is, why somehow similar testcase legitimizes the
address correctly with -fpic, while the original testcase doesn't.
My impressions are most of PIC addresses like:
6: r92:DI=[const(unspec[`G'] 2)]
7: r91:DI=r92:DI
REG_EQUAL `G'
8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
is generated by x86 backend vi ix86_expand_move and x86 backend was never
presented with other opportunities before. X86 backend isn't prepared to
handle some RTL expansions from offload.
The x86 backend did survive many years just fine, so I think offload should be
fixed to follow approach that generic middle-end takes. The testcase I posted
expands without problems; in this case middle-end knows that symbol address has
to be moved to a register. It looks like offload bypasses generic expansion
functions (that would magically fix this issue).
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- That's strange, it should only affect targets that define _GLIBCXX_HAVE_BROKEN_VSWPRINTF i.e. only mingw What are the full errors in the libstdc++-v3/testsuite/libstdc++.log file?
[Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Probably the same issue as PR 64368 so it's probably a problem with the non-gnu clocale model.
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 Colin Pitrat colin.pitrat+gcc at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Colin Pitrat colin.pitrat+gcc at gmail dot com --- OK thank you, sorry for the bothering ! In the mean time I also discovered -Og that appeared in gcc 4.8, that provides optimization compatible with debugging and that have the same behavior. This allows me to have the same result with the release and the debug build, which is what was the issue for me. I'm still surprised by the fact that -Og or -O1 seems to be more than just the list of -f flags it activates, as providing only them doesn't trigger this same behaviour. I couldn't find another responsible flag in the difference I found in the output of --help=warnings,target,params,c or common Closing this bug as invalid. Regards, Colin
[Bug ipa/64447] New: [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 Bug ID: 64447 Summary: [5 Regression] FAIL: gcc.dg/vect/slp-9.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz On Linux/ia32, r219108 caused: FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorizing stmts using SLP 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect vectorizing stmts using SLP 1
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-30 CC||dje at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 Severity|normal |blocker --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed. This causes bootstrap failure on AIX. src/src/libstdc++-v3/src/c++11/system_error.cc:179:1: internal compiler error: in operator[], at vec.h:736 } // namespace ^
[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596 --- Comment #2 from Jiong Wang jiwang at gcc dot gnu.org --- we are also lack of initialization for va_list_gpr_counter_field and va_list_vpr_counter_field, thus currently the whole tree-stdarg optimization doesn't work for AArch64, and lots of other targets, like arm, sparc, mips etc are lack of this vaarg opt tuning also.
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 --- Comment #2 from Tejas Belagod belagod at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #1) That's strange, it should only affect targets that define _GLIBCXX_HAVE_BROKEN_VSWPRINTF i.e. only mingw What are the full errors in the libstdc++-v3/testsuite/libstdc++.log file? .../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/./gcc/xg++ -shared-libgcc -B.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/./gcc -nostdinc++ -L.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/src -L.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/src/.libs -L.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/libsupc++/.libs -B.../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/bin/ -B.../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/lib/ -isystem .../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/include -isystem .../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/sys-include -B.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR=. -nostdinc++ -I.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf -I.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include -I.../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/libsupc++ -I.../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/include/backward -I.../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/util .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc -std=gnu++11 ./libtestc++.a -specs=aem-ve.specs -lm -mcmodel=small -fPIC -o ./dr1261.exe^M .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc: In function 'void test01()':^M .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:31:32: error: 'to_string' was not declared in this scope^M const string one(to_string(-2));^M ^^M compiler exited with status 1 output is: .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc: In function 'void test01()':^M .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:31:32: error: 'to_string' was not declared in this scope^M const string one(to_string(-2));^M ^^M FAIL: 21_strings/basic_string/numeric_conversions/char/dr1261.cc (test for excess errors) Excess errors: .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:31:32: error: 'to_string' was not declared in this scope UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/dr1261.cc compilation failed to produce executable extra_tool_flags are: -std=gnu++11
[Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 --- Comment #3 from Tejas Belagod belagod at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) This commit seems to be breaking libstdc++-v3 runs on AArch64. Is this under Linux or with newlib? newlib. When run on a fast-model(simulator) they fail by raising an exception. I'll post more info on the kind of exception rasied when I've investigated a bit more...
[Bug target/53987] [SH] Unnecessary zero-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Dec 30 17:26:18 2014 New Revision: 219110 URL: https://gcc.gnu.org/viewcvs?rev=219110root=gccview=rev Log: gcc/testsuite/ PR target/53987 * gcc.target/sh/pr53987-1.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr53987-1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/64448] New: New middle-end pattern breaks vector BIF folding on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64448
Bug ID: 64448
Summary: New middle-end pattern breaks vector BIF folding on
AArch64.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This new pattern
Author: mpolacek mpolacek@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Dec 17 11:48:33 2014 +
PR middle-end/63568
match.pd: Add (x ~m) | (y m) - ((x ^ y) m) ^ x pattern.
gcc.dg/pr63568.c: New test.
breaks BSL folding to a BIF on AArch64.
Causes this regression:
FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\\tv 1
The code now generated is:
vbslq_dummy_u32:
eorv0.16b, v1.16b, v0.16b
andv0.16b, v0.16b, v2.16b
eorv0.16b, v1.16b, v0.16b
ret
.sizevbslq_dummy_u32, .-vbslq_dummy_
instead of:
vbslq_dummy_u32:
bifv0.16b, v1.16b, v2.16b
ret
.sizevbslq_dummy_u32, .-vbslq_dummy_u32
Optimized tree when folding happens:
vbslq_dummy_u32 (uint32x4_t a, uint32x4_t b, uint32x4_t mask)
{
__Uint32x4_t _3;
__Uint32x4_t _4;
__Uint32x4_t _6;
uint32x4_t _7;
bb 2:
_3 = mask_1(D) a_2(D);
_4 = ~mask_1(D);
_6 = _4 b_5(D);
_7 = _3 | _6;
return _7;
}
Optimized tree where folding does not happen:
vbslq_dummy_u32 (uint32x4_t a, uint32x4_t b, uint32x4_t mask)
{
__Uint32x4_t _3;
__Uint32x4_t _5;
uint32x4_t _6;
bb 2:
_3 = b_1(D) ^ a_2(D);
_5 = _3 mask_4(D);
_6 = b_1(D) ^ _5;
return _6;
}
This will probably need another idiom to be caught by the BSL - BIF folder.
[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Jiong Wang from comment #2) we are also lack of initialization for va_list_gpr_counter_field and va_list_vpr_counter_field, thus currently the whole tree-stdarg optimization doesn't work for AArch64, and lots of other targets, like arm, sparc, mips etc are lack of this vaarg opt tuning also. Yes but the two other server targets (x86 and PowerPC) don't lack this optimization.
[Bug target/49263] SH Target: underutilized TST #imm, R0 instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #23 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Dec 30 18:44:27 2014 New Revision: 219111 URL: https://gcc.gnu.org/viewcvs?rev=219111root=gccview=rev Log: gcc/testsuite/ PR target/49263 * gcc.target/sh/pr49263-1.c: New. * gcc.target/sh/pr49263-2.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr49263-1.c trunk/gcc/testsuite/gcc.target/sh/pr49263-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #195 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Martin von Gagern from comment #193) Would it make sense to file one bug report per language, marking all of them as blocking this one here, so we can keep track of progress per language? I'm particularly interested in C++, but I guess others might care for other front-ends. Feel free to do just that, specially if you are planning to work on it. This PR has become too long and full of outdated info (and useless comments) to be really useful.
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Colin Pitrat from comment #4) In the mean time I also discovered -Og that appeared in gcc 4.8, that provides optimization compatible with debugging and that have the same behavior. This allows me to have the same result with the release and the debug build, which is what was the issue for me. That seems fragile to me, that is, likely to not work for different testcases or compiler versions. The official (non-wiki) FAQ for this is seriously lacking info, and it is certainly a bug in many cases that GCC does not implement standard-mandated behavior for excess precission. Fortunately, this is (or should be) fixed for C. See https://gcc.gnu.org/wiki/FAQ#PR323 and the links therein. I'm still surprised by the fact that -Og or -O1 seems to be more than just the list of -f flags it activates, as providing only them doesn't trigger this same behaviour. I couldn't find another responsible flag in the difference I found in the output of --help=warnings,target,params,c or common https://gcc.gnu.org/wiki/FAQ#optimization-options
[Bug target/49263] SH Target: underutilized TST #imm, R0 instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #24 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Dec 30 19:11:42 2014 New Revision: 219113 URL: https://gcc.gnu.org/viewcvs?rev=219113root=gccview=rev Log: gcc/testsuite/ PR target/49263 * gcc.target/sh/sh.exp (check_effective_target_sh2a): New. * gcc.target/sh/pr49263-3.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr49263-3.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/sh.exp
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=323#c127 --- Comment #196 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I believe the latest status of this PR is explained by comment 127. I added this as the URL of the bug for people to find. Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) is seriously lacking info and outdated. From now on, I'll point people to: https://gcc.gnu.org/wiki/FAQ#PR323
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-30 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Oh, I think I'm just an idiot and shouldn't have changed those tests.
[Bug libstdc++/64449] New: /usr/ccs/bin/ld: Unsatisfied symbols: std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::copy(wchar_t*, unsigned long, unsigned long)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64449 Bug ID: 64449 Summary: /usr/ccs/bin/ld: Unsatisfied symbols: std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::copy(wchar_t*, unsigned long, unsigned long) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.00 hppa1.1-hp-hpux10.20 Target: hppa2.0w-hp-hpux11.00 hppa1.1-hp-hpux10.20 Build: hppa2.0w-hp-hpux11.00 hppa1.1-hp-hpux10.20 On hppa2.0w-hp-hpux11.00 in stage2, we have the following unsatisfied symbols: /xxx/gnu/gcc/objdir/./prev-gcc/xg++ -B/xxx/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu /gcc/gcc-5.0/hppa2.0w-hp-hpux11.00/bin/ -nostdinc++ -B/xxx/gnu/gcc/objdir/prev-h ppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs -B/xxx/gnu/gcc/objdir/prev-hppa2.0w- hp-hpux11.00/libstdc++-v3/libsupc++/.libs -I/xxx/gnu/gcc/objdir/prev-hppa2.0w-h p-hpux11.00/libstdc++-v3/include/hppa2.0w-hp-hpux11.00 -I/xxx/gnu/gcc/objdir/pr ev-hppa2.0w-hp-hpux11.00/libstdc++-v3/include -I/xxx/gnu/gcc/gcc/libstdc++-v3/l ibsupc++ -L/xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs -L/xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -W all -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wover loaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-str ings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o c c1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck. o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-array-notation .o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-form at.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c -family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-prin t.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/ array-notation-common.o c-family/cilk.o c-family/c-ubsan.o default-c.o \ cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a l ibcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libc pp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../l ibdecnumber/libdecnumber.a -L/opt/gnu/gcc/gmp/lib -lmpc -lmpfr -lgmp -L../zlib -lz /usr/ccs/bin/ld: Unsatisfied symbols: std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::copy(wchar_t*, unsigned long, unsigned long) const (first referenced in /xxx /gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libstdc++.a(co w-shim_facets.o)) (code) std::__cxx11::basic_stringwchar_t, std::char_traitswchar_t, std::allocator wchar_t ::copy(wchar_t*, unsigned long, unsigned long) const (first reference d in /xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libst dc++.a(cxx11-shim_facets.o)) (code) std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::_Rep::_S_empty_rep_storage (first referenced in /xxx/gnu/gcc/objdir/prev-hpp a2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libstdc++.a(cow-shim_facets.o)) (data) wchar_t* std::basic_stringwchar_t, std::char_traitswchar_t, std::allocator wchar_t ::_S_constructwchar_t const*(wchar_t const*, wchar_t const*, std::a llocatorwchar_t const, std::forward_iterator_tag) (first referenced in /xxx/g nu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libstdc++.a(cow- shim_facets.o)) (code) std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::basic_string(wchar_t const*, std::allocatorwchar_t const) (first referenc ed in /xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libs tdc++.a(cow-shim_facets.o)) (code) collect2: error: ld returned 1 exit status With hppa1.1-hp-hpux10.20, we have: /xxx/gnu/gcc/objdir/./prev-gcc/xg++ -B/xxx/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu/gcc/gcc-5.0/hppa1.1-hp-hpux10.20/bin/ -nostdinc++ -B/xxx/gnu/gcc/objdir/prev-hp pa1.1-hp-hpux10.20/libstdc++-v3/src/.libs -B/xxx/gnu/gcc/objdir/prev-hppa1.1-hp- hpux10.20/libstdc++-v3/libsupc++/.libs -isystem /xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/include/hppa1.1-hp-hpux10.20 -isystem /xxx/gnu/gcc/ objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/include -isystem /xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc+ +-v3/src/.libs -L/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org --- Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility build_ssa_passes chkp_passes opt_local_passes free-inline-summary whole-program profile_estimate icf devirt cp cdtor inline /home/dje/src/src/libstdc++-v3/src/c++98/bitmap_allocator.cc: At global scope: /home/dje/src/src/libstdc++-v3/src/c++98/bitmap_allocator.cc:127:1: internal compiler error: in inline_merge_summary, at ipa-inline-analysis.c:3611 } // namespace ^ #0 _Z11fancy_abortPKciS0_ ( file=0x122ab320 internal_fn_flags_array+34512 /home/dje/src/src/gcc/ipa-inline-analysis.c, line=3611, function=0x122ac260 internal_fn_flags_array+38416 inline_merge_summary) at /home/dje/src/src/gcc/diagnostic.c:1288 #1 0x10e5ff5c in _Z20inline_merge_summaryP11cgraph_edge (edge=0x70404480) at /home/dje/src/src/gcc/ipa-inline-analysis.c:3611 #2 0x11a26db4 in _Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb (e=0x70404480, update_original=true, new_edges=incomplete type, overall_size=0x30494f2c _ipainline.bss_, update_overall_summary=true, callee_removed=0x0) at /home/dje/src/src/gcc/ipa-inline-transform.c:326 #3 0x10fd7694 in _ZL22inline_small_functionsv () at /home/dje/src/src/gcc/ipa-inline.c:1813 #4 0x10fd8ebc in _ZL10ipa_inlinev () at /home/dje/src/src/gcc/ipa-inline.c:2185 #5 0x10fda344 in _ZN50_GLOBAL__N__Z20speculation_useful_pP11cgraph_edgeb15pass_ipa_inline7executeEP8function (this=0x304cfc28) at /home/dje/src/src/gcc/ipa-inline.c:2558 #6 0x101a4350 in _Z16execute_one_passP8opt_pass (pass=0x304cfc28) at /home/dje/src/src/gcc/passes.c:2311 #7 0x101a5924 in _Z21execute_ipa_pass_listP8opt_pass (pass=0x304cfc28) at /home/dje/src/src/gcc/passes.c:2708 #8 0x10d9f654 in _ZL10ipa_passesv () at /home/dje/src/src/gcc/cgraphunit.c:2124 #9 0x10d9faf8 in _ZN12symbol_table7compileEv (this=0x7000a000) at /home/dje/src/src/gcc/cgraphunit.c:2212 #10 0x10da0074 in _ZN12symbol_table25finalize_compilation_unitEv ( this=0x7000a000) at /home/dje/src/src/gcc/cgraphunit.c:2361 #11 0x106b9078 in _Z28cp_write_global_declarationsv () at /home/dje/src/src/gcc/cp/decl2.c:4742 #12 0x10002ca8 in _ZL12compile_filev () at /home/dje/src/src/gcc/toplev.c:584 #13 0x10006648 in _ZL10do_compilev () at /home/dje/src/src/gcc/toplev.c:2018 #14 0x10006a10 in _ZN6toplev4mainEiPPc (this=0x2ff22ab8, argc=7, argv=0x2ff22b68) at /home/dje/src/src/gcc/toplev.c:2115 #15 0x1740 in main (argc=7, argv=0x2ff22b68) at /home/dje/src/src/gcc/main.c:38
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 --- Comment #1 from dave.anglin at bell dot net --- On 2014-12-23, at 12:31 PM, hjl.tools at gmail dot com wrote: On Linux/x86-64, r219037 caused FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3) FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final insn[: ][^\n]*set \\(mem(?![^\n]*scratch) The optimization could easily be restored if there was a procedure or target hook to provide a way to determine if a sibcall may read from the frame. On hppa-linux, this would be true if the sibcall arguments were all passed in registers. It might be possible to do this by analyzing the decl. The dse pass avoids looking at call usage information. -- John David Anglindave.ang...@bell.net
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-30 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to dave.anglin from comment #1) On 2014-12-23, at 12:31 PM, hjl.tools at gmail dot com wrote: On Linux/x86-64, r219037 caused FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3) FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final insn[: ][^\n]*set \\(mem(?![^\n]*scratch) The optimization could easily be restored if there was a procedure or target hook to provide a way to determine if a sibcall may read from the frame. On hppa-linux, this would be true if the sibcall arguments were all passed in registers. It might be possible to do this by analyzing the decl. Can you add such a hook? Thanks.
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from John David Anglin danglin at gcc dot gnu.org --- And ICE on hppa2.0w-hp-hpux11.11: libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gc c/objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc+ +-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/ test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gn u/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux 11.11/lib/ -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include -I/test/gnu/gcc/gcc/libst dc++-v3/../libgcc -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/incl ude/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++ -v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-im plicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-s how-location=once -frandom-seed=eh_alloc.lo -g -O2 -c ../../../../gcc/libstdc++- v3/libsupc++/eh_alloc.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o eh_alloc.o ../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc:211:1: internal compiler erro r: in inline_merge_summary, at ipa-inline-analysis.c:3611 } ^
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
the problem is that estimate_function_body_sizes frees ipa_free_all_node_params
when called late via add_new_function.
the following patch should fix it.
Honza
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c(revision 219108)
+++ ipa-inline-analysis.c(working copy)
@@ -2851,7 +2851,7 @@ estimate_function_body_sizes (struct cgr
{
if (!early)
loop_optimizer_finalize ();
- else
+ else if (!ipa_edge_args_vector)
ipa_free_all_node_params ();
free_dominance_info (CDI_DOMINATORS);
}
[Bug c++/64450] New: Optimize 0=p-q to q=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 Bug ID: 64450 Summary: Optimize 0=p-q to q=p for char*p,*q; Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Created attachment 34365 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34365action=edit Testcase It was noticed that Boost's iterator_facade incurred a performance penalty (while it should ideally be zero-overhead), which results from the fact that GCC does not optimize 0=p-q to q=p for char*p,*q;. See attachment. This probably applies to and and = as well.
[Bug c++/64450] Optimize 0=p-q to q=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-30 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug fortran/64416] RFE: Support REAL128 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- The Procedure Call Standard for the ARM Architecture does not include a 128-bit floating-point type, so if you want to support such a type in GCC for ARM you should first work with arm.e...@arm.com to define the associated ABI and get a new version of AAPCS released. Or you could use AArch64 - AAPCS64 does include such a type.
[Bug tree-optimization/64450] Optimize 0=p-q to q=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- See also PR61734, Eric already tried in May.
[Bug tree-optimization/64450] Optimize 0=p-q to q=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Marc Glisse from comment #1) See also PR61734, Eric already tried in May. Maybe it is easier to handle now with simplify-and-match.
[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384
daniel.c.klauer at web dot de changed:
What|Removed |Added
CC||daniel.c.klauer at web dot de
--- Comment #3 from daniel.c.klauer at web dot de ---
It seems there is a difference between gcc and ms with regards to return in
register for C++ methods (regardless of stdcall/cdecl/thiscall).
Tested with i686-w64-mingw32 gcc 4.9.2 and cl.exe from VS 2010:
struct A {
int field1;
};
struct A getA(void) {
struct A a = {123};
return a;
}
C function: both gcc and ms return in register (struct is small enough), ok.
struct A {
int field1;
};
class Test {
public:
A getA();
};
A Test::getA() {
struct A a = {123};
return a;
}
C++ method: ms returns in temp var on stack (as for big structs), but gcc
returns in register.
The same happens for struct containing two floats (as in the original crash
issue reported on mingw-w64 mailing list).
Maybe (on 32bit) ms never uses return in register for C++ methods with
aggregate result?
[Bug target/64451] New: tic6x-elf: ICE in extract_insn, at recog.c:2202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451 Bug ID: 64451 Summary: tic6x-elf: ICE in extract_insn, at recog.c:2202 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yselkowi at redhat dot com While building gcc-4.9.2 --target=tic6x-elf with newlib-2.2.0: libtool: compile: /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/tic6x-elf/./gcc/xgcc -B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/tic6x-elf/./gcc/ -B/usr/tic6x-elf/bin/ -B/usr/tic6x-elf/lib/ -isystem /usr/tic6x-elf/include -isystem /usr/tic6x-elf/sys-include -DHAVE_CONFIG_H -I. -I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp -Wall -g -ggdb -O2 -pipe -Wimplicit-function-declaration -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c -o ssp.o /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c: In function ‘fail.isra.0’: /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:163:1: error: unrecognizable insn: } ^ (insn 111 110 112 16 (set (mem/v:SI (reg/f:SI 111) [3 MEM[(volatile int *)4294967295B]+0 S4 A8]) (unspec:SI [ (reg:SI 112) ] UNSPEC_MISALIGNED_ACCESS)) /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:156 -1 (nil)) /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:163:1: internal compiler error: in extract_insn, at recog.c:2202
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 --- Comment #3 from dave.anglin at bell dot net --- Hi H.J., On 2014-12-30, at 3:13 PM, hjl.tools at gmail dot com wrote: Can you add such a hook? I'm sorry but realistically I don't have the spare time to work on this bug. Dave -- John David Anglindave.ang...@bell.net
[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384 --- Comment #4 from mity mity at morous dot org --- Daniel, COM interface should be, by definition, language agnostic. COM can be called from C++ as well as from C, and also COM object may be implemented in C++ as well as C. This implies that (at least for stdcall, as COM uses stdcall convention) there shouldn't be any difference between C and C++.
[Bug ipa/64444] [5 Regression] ICE: in inline_merge_summary, at ipa-inline-analysis.c:3611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed by r219114.
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed by r219114.
[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681 --- Comment #6 from Yaakov Selkowitz yselkowi at redhat dot com --- (In reply to Mikael Pettersson from comment #5) The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with r210683. Backporting r210683 to current 4.9 branch is easy and fixes the ICE there too. I haven't checked c6x. r210683 fixes this particular issue in 4.9.2 for both bfin-elf and tic6x-elf. (There is another, seemingly unrelated issue with the latter, see bug 64451.) Any chance this could get into 4.9.3?
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #197 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Manuel López-Ibáñez from comment #196) Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) is seriously lacking info and outdated. From now on, I'll point people to: https://gcc.gnu.org/wiki/FAQ#PR323 Note that this bug was mainly about the excess precision of x87 FPU, though its summary just says optimized code gives strange floating point results. But the users should be aware that the floating-point results can still depend on the optimization level because this is allowed by the ISO C standard. For instance, if one has code like x*y+z, a FMA can be used or not depending on the target architecture and the optimization level (see also bug 37845 about this), and this can change the results.
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- I still see: FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorizing stmts using SLP 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect vectorizing stmts using SLP 1 with r219114: https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg03418.html
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #198 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Vincent Lefèvre from comment #197) (In reply to Manuel López-Ibáñez from comment #196) Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) is seriously lacking info and outdated. From now on, I'll point people to: https://gcc.gnu.org/wiki/FAQ#PR323 Note that this bug was mainly about the excess precision of x87 FPU, though I added your comment to the FAQ but feel welcome to extend it: https://gcc.gnu.org/wiki/FAQ#PR323 What it is also missing is a criteria to distinguish normal behavior from actual GCC bugs (and there are GCC bugs like bug 37845 and others for optimizations that should only be done with ffast-math). Currently, any floating-point issue is likely to end up here.
[PATCH/expand] PR64011 Adjust bitsize when partial overflow happen for big-endian
PR64011 is actually a general problem on all target support bit insertion instructions. we overflow check at the start of store_bit_field_1, but that only check the situation where the field lies completely outside the register, while there do have situation where the field lies partly in the register, we need to adjust bitsize for this partial overflow situation. Without this fix, pr48335-2.c on big-endian will broken on those arch support bit insert instruction, like arm, aarch64. the testcase is just pr48335-2.c, before this patch is will ICE on arm and = generate invalid assembly on AArch64. after this patch, problem gone away. ok for trunk? bootstrap OK on x86-64 aarch64. no regression on x86-64 thanks. gcc/ PR64011 * expmed.c (store_bit_field_using_insv): Adjust bitsize when there is partial overflow. diff --git a/gcc/expmed.c b/gcc/expmed.c index 0304e46..61aec39 100644 --- a/gcc/expmed.c +++ b/gcc/expmed.c @@ -535,6 +535,16 @@ store_bit_field_using_insv (const extraction_insn *insv, rtx op0, copy_back = true; } + /* There are similar overflow check at the start of store_bit_field_1, + but that only check the situation where the field lies completely + outside the register, while there do have situation where the field + lies partialy in the register, we need to adjust bitsize for this + partial overflow situation. Without this fix, pr48335-2.c on big-endian + will broken on those arch support bit insert instruction, like arm, aarch64 + etc. */ + if (bitsize + bitnum unit bitnum unit) +bitsize = unit - bitnum; + /* If BITS_BIG_ENDIAN is zero on a BYTES_BIG_ENDIAN machine, we count backwards from the size of the unit we are inserting into. Otherwise, we count bits from the most significant on a
Re: [PATCH, i386] Remove EBX usage from asm code
On Mon, Dec 29, 2014 at 4:29 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
Missed path in ChangeLog:
2014-12-28 Evgeny Stupachenko evstu...@gmail.com
* config/i386/gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register
usage.
* config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.
Looks OK, but I'd like to ask Jakub (CC'd) about glibc impact before
the patch is approved.
Uros.
On Sun, Dec 28, 2014 at 7:46 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
Hi,
The patch removes EBX usage from asm code used in libgcc/crtstuff.c
It is safe now, but potentially buggy when glibc is rebuild with GCC
5.0 as EBX is not GOT register any more.
x86 bootstrap, make check passed.
Is it ok?
Evgeny
2014-12-28 Evgeny Stupachenko evstu...@gmail.com
* gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage.
* config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.
diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
index e1163c9..965673b 100644
--- a/gcc/config/i386/gnu-user.h
+++ b/gcc/config/i386/gnu-user.h
@@ -131,13 +131,6 @@ along with GCC; see the file COPYING3. If not see
/* Used by crtstuff.c to initialize the base of data-relative relocations.
These are GOT relative on x86, so return the pic register. */
-#ifdef __PIC__
-#define CRT_GET_RFIB_DATA(BASE)\
- {\
-register void *ebx_ __asm__(ebx);\
-BASE = ebx_; \
- }
-#else
#define CRT_GET_RFIB_DATA(BASE)
\
__asm__ (call\t.LPR%=\n\
.LPR%=:\n\t\
@@ -148,7 +141,6 @@ along with GCC; see the file COPYING3. If not see
add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0 \
|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)} \
: =d(BASE))
-#endif
#ifdef TARGET_LIBC_PROVIDES_SSP
/* i386 glibc provides __stack_chk_guard in %gs:0x14. */
diff --git a/gcc/config/i386/sysv4.h b/gcc/config/i386/sysv4.h
index 011b228..5167485 100644
--- a/gcc/config/i386/sysv4.h
+++ b/gcc/config/i386/sysv4.h
@@ -52,13 +52,6 @@ along with GCC; see the file COPYING3. If not see
/* Used by crtstuff.c to initialize the base of data-relative relocations.
These are GOT relative on x86, so return the pic register. */
-#ifdef __PIC__
-#define CRT_GET_RFIB_DATA(BASE)\
- {\
-register void *ebx_ __asm__(ebx);\
-BASE = ebx_; \
- }
-#else
#define CRT_GET_RFIB_DATA(BASE)
\
__asm__ (call\t.LPR%=\n\
.LPR%=:\n\t\
@@ -69,4 +62,3 @@ along with GCC; see the file COPYING3. If not see
add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0 \
|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)} \
: =d(BASE))
-#endif
Strenghten early inliner analysis
Hi,
this patch enables inline predicates for early inlining, too. This is easy to
do because
we do have call stmt around and know if parameters are constants.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-inline-analyssi.c (edge_set_predicate): Reset size/time when
target is UNREACHABLE.
(evaluate_properties_for_edge): If call statemet is available, use it
to determine compile time constants.
(estimate_function_body_sizes): Enable predicates for early inliner.
(estimate_calls_size_and_time): Speedup.
(inline_merge_summary): Evaluate properties for early inliner, too.
* gcc.dg/ipa/inline-7.c: New testcase.
===
--- ipa-inline-analysis.c (revision 219107)
+++ ipa-inline-analysis.c (working copy)
@@ -770,6 +770,8 @@ edge_set_predicate (struct cgraph_edge *
e-redirect_callee (cgraph_node::get_create
(builtin_decl_implicit (BUILT_IN_UNREACHABLE)));
e-inline_failed = CIF_UNREACHABLE;
+ es-call_stmt_size = 0;
+ es-call_stmt_time = 0;
if (callee)
callee-remove_symbol_and_inline_clones ();
}
@@ -940,6 +942,14 @@ evaluate_properties_for_edge (struct cgr
{
struct ipa_jump_func *jf = ipa_get_ith_jump_func (args, i);
tree cst = ipa_value_from_jfunc (parms_info, jf);
+
+ if (!cst e-call_stmt
+ i (int)gimple_call_num_args (e-call_stmt))
+ {
+ cst = gimple_call_arg (e-call_stmt, i);
+ if (!is_gimple_min_invariant (cst))
+ cst = NULL;
+ }
if (cst)
{
gcc_checking_assert (TREE_CODE (cst) != TREE_BINFO);
@@ -958,6 +968,22 @@ evaluate_properties_for_edge (struct cgr
known_aggs[i] = jf-agg;
}
}
+ else if (e-call_stmt !e-call_stmt_cannot_inline_p
+ ((clause_ptr info-conds) || known_vals_ptr))
+{
+ int i, count = (int)gimple_call_num_args (e-call_stmt);
+
+ if (count (info-conds || known_vals_ptr))
+ known_vals.safe_grow_cleared (count);
+ for (i = 0; i count; i++)
+ {
+ tree cst = gimple_call_arg (e-call_stmt, i);
+ if (!is_gimple_min_invariant (cst))
+ cst = NULL;
+ if (cst)
+ known_vals[i] = cst;
+ }
+}
if (clause_ptr)
*clause_ptr = evaluate_conditions_for_known_args (callee, inline_p,
@@ -2464,10 +2490,22 @@ estimate_function_body_sizes (struct cgr
info-conds = NULL;
info-entry = NULL;
- if (opt_for_fn (node-decl, optimize) !early)
+ /* When optimizing and analyzing for IPA inliner, initialize loop optimizer
+ so we can produce proper inline hints.
+
+ When optimizing and analyzing for early inliner, initialize node params
+ so we can produce correct BB predicates. */
+
+ if (opt_for_fn (node-decl, optimize))
{
calculate_dominance_info (CDI_DOMINATORS);
- loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS);
+ if (!early)
+loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS);
+ else
+ {
+ ipa_check_create_node_params ();
+ ipa_initialize_node_params (node);
+ }
if (ipa_node_params_sum)
{
@@ -2704,7 +2742,7 @@ estimate_function_body_sizes (struct cgr
time = MAX_TIME;
free (order);
- if (!early nonconstant_names.exists ())
+ if (nonconstant_names.exists () !early)
{
struct loop *loop;
predicate loop_iterations = true_predicate ();
@@ -2809,9 +2847,12 @@ estimate_function_body_sizes (struct cgr
inline_summaries-get (node)-self_time = time;
inline_summaries-get (node)-self_size = size;
nonconstant_names.release ();
- if (opt_for_fn (node-decl, optimize) !early)
+ if (opt_for_fn (node-decl, optimize))
{
- loop_optimizer_finalize ();
+ if (!early)
+loop_optimizer_finalize ();
+ else
+ ipa_free_all_node_params ();
free_dominance_info (CDI_DOMINATORS);
}
if (dump_file)
@@ -3062,6 +3103,13 @@ estimate_calls_size_and_time (struct cgr
for (e = node-callees; e; e = e-next_callee)
{
struct inline_edge_summary *es = inline_edge_summary (e);
+
+ /* Do not care about zero sized builtins. */
+ if (e-inline_failed !es-call_stmt_size)
+ {
+ gcc_checking_assert (!es-call_stmt_time);
+ continue;
+ }
if (!es-predicate
|| evaluate_predicate (es-predicate, possible_truths))
{
@@ -3522,13 +3570,14 @@ inline_merge_summary (struct cgraph_edge
else
toplev_predicate = true_predicate ();
+ if (callee_info-conds)
+evaluate_properties_for_edge (edge, true, clause, NULL, NULL, NULL);
if (ipa_node_params_sum callee_info-conds)
{
struct ipa_edge_args *args = IPA_EDGE_REF (edge);
int count = ipa_get_cs_argument_count (args);
Re: Strenghten early inliner analysis
On 2014.12.30 at 12:37 +0100, Jan Hubicka wrote: Hi, this patch enables inline predicates for early inlining, too. This is easy to do because we do have call stmt around and know if parameters are constants. Bootstrapped/regtested x86_64-linux, comitted. This causes Firefox LTO build on ppc64 to fail: /home/trippels/gcc_test/usr/local/bin/c++ -fPIC -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Werror=endif-labels -Werror=int-to-pointer-cast -Werror=missing-braces -Werror=pointer-arith -Werror=return-type -Werror=sequence-point -Werror=unused-label -Werror=trigraphs -Werror=type-limits -Wno-invalid-offsetof -Wcast-align -flto=80 --param lto-partitions=80 -mcpu=power8 -ffunction-sections -fdata-sections -fno-exceptions -fno-strict-aliasing -frtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -UDEBUG -DNDEBUG -O3 -DU_STATIC_IMPLEMENTATION -fvisibility=hidden -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-unused -Wno-unused-parameter -lpthread -Wl,--hash-style=gnu,--as-needed,--gc-sections,--icf=all -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -Wl,--gc-sections -o ../../bin/genrb errmsg.o genrb.o parse.o read.o reslist.o ustr.o rbutil.o wrtjava.o rle.o wrtxml.o prscmnts.o -L../../lib -licutu -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lpthread -ldl -lm lto1: internal compiler error: in inline_merge_summary, at ipa-inline-analysis.c:3611 0x10490b63 inline_merge_summary(cgraph_edge*) ../../gcc/gcc/ipa-inline-analysis.c:3611 0x10d0fa4b inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*, int*, bool, bool*) ../../gcc/gcc/ipa-inline-transform.c:326 0x10d07b1b inline_small_functions ../../gcc/gcc/ipa-inline.c:1813 0x10d07b1b ipa_inline ../../gcc/gcc/ipa-inline.c:2185 0x10d07b1b execute ../../gcc/gcc/ipa-inline.c:2558 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. lto-wrapper: fatal error: /home/trippels/gcc_test/usr/local/bin/c++ returned 1 exit status Will open a bug report later. -- Markus
Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length
Hi Dominique,
thanks for pointing that out. That was caused by a flaw in the current patch.
In the attached version this is fixed now.
Bootstraps and regtests ok on x86_64-linux-gnu.
Regards,
Andre
On Mon, 29 Dec 2014 16:32:27 +0100
Dominique d'Humières domi...@lps.ens.fr wrote:
For the record, compiling the tests in pr61337 with the patch applied on top
of r219099 gives ICEs:
use array_list
1
internal compiler error: in gfc_advance_chain, at fortran/trans.c:58
Since this replaces some wrong-code generation by some ICEs, I don’t think
this should delay the fix of pr60255.
Cheers,
Dominique
Le 29 déc. 2014 à 11:07, Andre Vehreschild ve...@gmx.de a écrit :
Hi all,
attached is the patch and changelog for fixing pr60255. All comments I
received have been integrated into the current patch, therefore I submit
this patch as final and hope to see it in trunk soon.
The patch fixes the assignment of deferred length char arrays to unlimited
polymorphic entities by introducing a _len component.
Bootstrapped and regtested ok on x86_64-linux-gnu.
As my system is rather slow in bootstrapping and regtesting here a preview
of what I plan to submit in the next two days:
- patch on pr60289: Took the proposal from Janus and extended to pass all
regtests and introduced new testcase.
- patch on pr60357 and pr55901: This incorporates Paul's patch on pr55901,
which I had to modify and extend to handle allocatable components including
deferred char arrays. I furthermore contains a patch from Tobias to correct
the attribute transport from the module to its place of use, which I
adapted to fully fix pr60357.
Regards,
Andre
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
pr60255_6.clog
Description: Binary data
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 5130022..3438826 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -34,6 +34,12 @@ along with GCC; see the file COPYING3. If not see
(pointer/allocatable/dimension/...).
* _vptr: A pointer to the vtable entry (see below) of the dynamic type.
+Only for unlimited polymorphic classes:
+* _len: An integer(4) to store the string length when the unlimited
+ polymorphic pointer is used to point to a char array. The '_len'
+ component will be zero when no character array is stored in
+ '_data'.
+
For each derived type we set up a vtable entry, i.e. a structure with the
following fields:
* _hash: A hash value serving as a unique identifier for this type.
@@ -544,10 +550,42 @@ gfc_intrinsic_hash_value (gfc_typespec *ts)
}
+/* Get the _len component from a class/derived object storing a string. */
+
+gfc_expr *
+gfc_get_len_component (gfc_expr *e)
+{
+ gfc_expr *len_comp;
+ gfc_ref *ref, **last;
+ len_comp = gfc_copy_expr (e-symtree-n.sym-assoc-target);
+
+ /* We need to remove the last _data component ref from ptr. */
+ last = (len_comp-ref);
+ ref = len_comp-ref;
+ while (ref)
+{
+ if (!ref-next
+ ref-type == REF_COMPONENT
+ strcmp (_data, ref-u.c.component-name)== 0)
+{
+ gfc_free_ref_list (ref);
+ *last = NULL;
+ break;
+}
+ last = (ref-next);
+ ref = ref-next;
+}
+ gfc_add_component_ref (len_comp, _len);
+ return len_comp;
+}
+
+
/* Build a polymorphic CLASS entity, using the symbol that comes from
build_sym. A CLASS entity is represented by an encapsulating type,
which contains the declared type as '_data' component, plus a pointer
- component '_vptr' which determines the dynamic type. */
+ component '_vptr' which determines the dynamic type. When this CLASS
+ entity is unlimited polymorphic, then also add a component '_len' to
+ store the length of string when that is stored in it. */
bool
gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
@@ -645,19 +683,36 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
if (!gfc_add_component (fclass, _vptr, c))
return false;
c-ts.type = BT_DERIVED;
+ c-attr.access = ACCESS_PRIVATE;
+ c-attr.pointer = 1;
if (ts-u.derived-attr.unlimited_polymorphic)
{
vtab = gfc_find_derived_vtab (ts-u.derived);
gcc_assert (vtab);
c-ts.u.derived = vtab-ts.u.derived;
+
+ /* Add component '_len'. Only unlimited polymorphic pointers may
+ have a string assigned to them, i.e., only those need the _len
+ component. */
+ if (!gfc_add_component (fclass, _len, c))
+ return false;
+ c-ts.type = BT_INTEGER;
+ c-ts.kind = 4;
+ c-attr.access = ACCESS_PRIVATE;
+ c-attr.artificial = 1;
+
+ /* Build minimal expression to initialize component with zero.
+
[PATCH, i386]: Use std::swap some more.
Hello!
2014-12-30 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (ix86_legitimize_address): Use std::swap.
(ix86_split_fp_branch): Ditto.
(ix86_expand_int_movcc): Ditto.
(ix86_expand_sse_compare): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} ,
committed to mainline SVN.
Uros.
Index: i386.c
===
--- i386.c (revision 219107)
+++ i386.c (working copy)
@@ -14362,9 +14362,7 @@ ix86_legitimize_address (rtx x, rtx, machine_mode
/* Put multiply first if it isn't already. */
if (GET_CODE (XEXP (x, 1)) == MULT)
{
- rtx tmp = XEXP (x, 0);
- XEXP (x, 0) = XEXP (x, 1);
- XEXP (x, 1) = tmp;
+ std::swap (XEXP (x, 0), XEXP (x, 1));
changed = 1;
}
@@ -20497,10 +20495,8 @@ ix86_split_fp_branch (enum rtx_code code, rtx op1,
if (target2 != pc_rtx)
{
- rtx tmp = target2;
+ std::swap (target1, target2);
code = reverse_condition_maybe_unordered (code);
- target2 = target1;
- target1 = tmp;
}
condition = ix86_expand_fp_compare (code, op1, op2,
@@ -20720,9 +20716,7 @@ ix86_expand_int_movcc (rtx operands[])
/* To simplify rest of code, restrict to the GEU case. */
if (compare_code == LTU)
{
- HOST_WIDE_INT tmp = ct;
- ct = cf;
- cf = tmp;
+ std::swap (ct, cf);
compare_code = reverse_condition (compare_code);
code = reverse_condition (code);
}
@@ -20754,9 +20748,7 @@ ix86_expand_int_movcc (rtx operands[])
code = reverse_condition (code);
else
{
- HOST_WIDE_INT tmp = ct;
- ct = cf;
- cf = tmp;
+ std::swap (ct, cf);
diff = ct - cf;
}
tmp = emit_store_flag (tmp, code, op0, op1, VOIDmode, 0, -1);
@@ -36036,12 +36028,7 @@ ix86_expand_sse_compare (const struct builtin_desc
/* Swap operands if we have a comparison that isn't available in
hardware. */
if (swap)
-{
- rtx tmp = gen_reg_rtx (mode1);
- emit_move_insn (tmp, op1);
- op1 = op0;
- op0 = tmp;
-}
+std::swap (op0, op1);
if (optimize || !target
|| GET_MODE (target) != tmode
RE: [PATCH] Don't check for optab for 16bit bswap
On December 29, 2014 7:44:13 PM CET, Oleg Endo oleg.e...@t-online.de wrote: On Mon, 2014-12-29 at 17:53 +, Thomas Preud'homme wrote: From: Richard Biener [mailto:rguent...@suse.de] Sent: Monday, December 29, 2014 5:09 PM OK, but what about targets without a rotation optab? Is the fallback expansion reasonable in all cases? To be honest I haven't checked. I thought being a treecode means it can always be expanded, using a sequence of shift and bitwise or if necessary. Isn't there some language that GCC support with rotate operators? Given your question I guess I was wrong assuming this. Is there a list of gimple construct that are necessary supported? What about a list of insn pattern that a backend must necessarily provide? __builtin_bswap16 expansion uses the 'rotlhi3' pattern to do a 16 bit bswap as a fallback when there's no 'bswaphi2' pattern in the backend (like on SH at the moment. I haven't added bswaphi2, as __builtin_bswap16 has been working without it). I've just tried disabling the 'rotlhi3' pattern and __builtin_bswap16 expands into shift + and + or (as expected). Thus, I don't think the patch will make something worse (than it already is) on some backends. If the bswap detection bails out at the tree level, the expanded ops will be shift + and + or -- as written in the original code. So probably, that will be the same as the fallback expansion for __builtin_bswap16, and we're back to sqrt (1). OK, that is what I was asking - are there cases where using rot is worse (like forcing a libcall or so). Richard. Cheers, Oleg
Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length
The new patch fixes the ICEs, but still emit the wrong codes reported in pr61337. Thanks and Happy New Year to all, Dominique Le 30 déc. 2014 à 14:39, Andre Vehreschild ve...@gmx.de a écrit : Hi Dominique, thanks for pointing that out. That was caused by a flaw in the current patch. In the attached version this is fixed now. Bootstraps and regtests ok on x86_64-linux-gnu. Regards, Andre On Mon, 29 Dec 2014 16:32:27 +0100 Dominique d'Humières domi...@lps.ens.fr wrote: For the record, compiling the tests in pr61337 with the patch applied on top of r219099 gives ICEs: use array_list 1 internal compiler error: in gfc_advance_chain, at fortran/trans.c:58 Since this replaces some wrong-code generation by some ICEs, I don’t think this should delay the fix of pr60255. Cheers, Dominique
Re: [wwwdocs] C++ SD-6 feature test column for cxx0x.html and cxx1y.html
On 12/27/2014 07:56 PM, Ed Smith-Rowland wrote: I would like peoples opinion of adding another column to the tables indicating C++ feature status for C++11 and C++14 that contains the relevant SD-6 feature macro. Sure, that makes sense. Jason
Re: [WWW] Update index.html and gcc-5/changes.html to reflect offloading changes.
Hi Gerald, On 27 Dec 12:07, Gerald Pfeifer wrote: On Friday 2014-12-12 14:43, Kirill Yukhin wrote: These change adds mention of OpenMP4 offloading support in GCC: in release notes and in news section of main page. good you thought of that, thank you! Index: htdocs/index.html === + dtspanOpenMP 4.0 offloading support in GCC/span + span class=date[2014-12-12]/span/dt + dda href=http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf; + OpenMP 4.0/a offloading features support was added to GCC. Generic changes: How about omitting features in the above? + liGeneric infrastructure (suitable for any vendor)./li + liTestsuite which covers offloading from + a href=http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf; + OpenMP 4.0 Examples/a document./li from the + Specific for upcoming Intel MIC products: Is everyone aware what MIC stands for, or is that the marketing name? + liRuntime library./li I believe that would be run-time library? +Contributed by Jakub Jelinek (RedHat), Thomas Schwinge (CodeSourcery), Red Hat. It's Red Hat. Two words. Why does everybody get this wrong? + Bernd Schmidt (CodeSourcery), Andrey Turetskiy (Intel), + Ilya Verbin (Intel) and Kirill Yukhin (Intel)./dd/dt How about if you contract this to Thomas Schwinge and Bernd Schmidt (CodeSourcery) and similarly for you guys from Intel? Incidently the alphabetical ordering nicely supports this here. Note: Schwinge Schmidt, so I think you'll want to switch those two. That said, overall this is a bit too long for an entry on the home page. Can you put all those details in the gcc-5/changes.html page (this is good material) and link to it from a shortened entry for the home page? Index: htdocs/gcc-5/changes.html === h2 id=languagesNew Languages and Language specific improvements/h2 + ul + lia href=http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf; OpenMP 4.0 + specification/a offloading features are now supported in C/C++ and + Fortran compiler/li + /ul supported by the C, C++ and Fortran compilers (plural) (This adds the, but also splits C and C++ which really are to different compilers in many ways. No need to be shy. ;-) Given the number of suggestions, in this case I'd prefer to have another look at an updated version. Now that I am back online, I should be able to turn this quickly. Thanks for extended review! I hope I taken into account all your inputs. Updated patch in the bottom. -- Thanks, K Index: htdocs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.942 diff -p -r1.942 index.html *** htdocs/index.html 17 Nov 2014 08:59:33 - 1.942 --- htdocs/index.html 30 Dec 2014 15:46:13 - *** mission statement/a./p *** 52,57 --- 52,76 dl class=news + dtspanOpenMP 4.0 offloading support in GCC/span + span class=date[2014-12-12]/span/dt + dda href=http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf; + OpenMP 4.0/a offloading support was added to GCC. + Contributed by Jakub Jelinek (Red Hat), Bernd Schmidt and + Thomas Schwinge (CodeSourcery), Andrey Turetskiy, + Ilya Verbin and Kirill Yukhin (Intel). a href=https://gcc.gnu.org/gcc-5/changes.html#offload; + Details./a/dd/dt + dtspana href=gcc-4.9/GCC 4.9.2/a released/span span class=date[2014-10-30]/span/dt dd/dd Index: htdocs/gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.50 diff -p -r1.50 changes.html *** htdocs/gcc-5/changes.html 10 Dec 2014 00:28:18 - 1.50 --- htdocs/gcc-5/changes.html 30 Dec 2014 15:46:13 - *** *** 83,88 --- 83,105 /ul h2 id=languagesNew Languages and Language specific improvements/h2 + ul + li id=offloada href=http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf; + OpenMP 4.0 specification/a offloading features are now supported by the C, C++, + and Fortran compilers. Generic changes: + ul + liInfrastructure (suitable for any vendor)./li + liTestsuite which covers offloading from the + a href=http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf; + OpenMP 4.0 Examples/a document./li + /ul + Specific for upcoming Intel Xeon Phi products: + ul + liRun-time library./li + liCard emulator./li + /ul + /li + /ul !-- h3 id=adaAda/h3 --
Re: [PATCH] Fix PR c++/59366 A friend function template defined in a class is found without ADL
On 12/28/2014 01:45 PM, Momchil Velikov wrote:
+ if (!hidden_friend)
+ {
+ DECL_ANTICIPATED (olddecl) = 0;
+ DECL_HIDDEN_FRIEND_P (olddecl) = 0;
+ }
Why not add this...
@@ -2147,10 +2160,6 @@ duplicate_decls (tree newdecl, tree olddecl, bool
newdecl_is_friend)
if (DECL_DECLARES_FUNCTION_P (newdecl))
{
DECL_NONCONVERTING_P (newdecl) = DECL_NONCONVERTING_P (olddecl);
- olddecl_friend = DECL_FRIEND_P (olddecl);
- hidden_friend = (DECL_ANTICIPATED (olddecl)
- DECL_HIDDEN_FRIEND_P (olddecl)
- newdecl_is_friend);
...here? I don't see a reason why a function template wouldn't hit this
block.
Jason
Re: [PATCH] Fix PR c++/59366 A friend function template defined in a class is found without ADL
On 30.12.2014 17:54, Jason Merrill wrote:
On 12/28/2014 01:45 PM, Momchil Velikov wrote:
+ if (!hidden_friend)
+{
+ DECL_ANTICIPATED (olddecl) = 0;
+ DECL_HIDDEN_FRIEND_P (olddecl) = 0;
+}
Why not add this...
@@ -2147,10 +2160,6 @@ duplicate_decls (tree newdecl, tree olddecl,
bool newdecl_is_friend)
if (DECL_DECLARES_FUNCTION_P (newdecl))
{
DECL_NONCONVERTING_P (newdecl) = DECL_NONCONVERTING_P (olddecl);
- olddecl_friend = DECL_FRIEND_P (olddecl);
- hidden_friend = (DECL_ANTICIPATED (olddecl)
-DECL_HIDDEN_FRIEND_P (olddecl)
-newdecl_is_friend);
...here? I don't see a reason why a function template wouldn't hit this
block.
A function template enters the body of the if statement at line 1881,
if (TREE_CODE (newdecl) == TEMPLATE_DECL)
and exits the function at line 1951 with
return olddecl;
RE: [PATCH] Don't check for optab for 16bit bswap
On Tue, 2014-12-30 at 16:22 +0100, Richard Biener wrote: On December 29, 2014 7:44:13 PM CET, Oleg Endo oleg.e...@t-online.de wrote: On Mon, 2014-12-29 at 17:53 +, Thomas Preud'homme wrote: From: Richard Biener [mailto:rguent...@suse.de] Sent: Monday, December 29, 2014 5:09 PM OK, but what about targets without a rotation optab? Is the fallback expansion reasonable in all cases? To be honest I haven't checked. I thought being a treecode means it can always be expanded, using a sequence of shift and bitwise or if necessary. Isn't there some language that GCC support with rotate operators? Given your question I guess I was wrong assuming this. Is there a list of gimple construct that are necessary supported? What about a list of insn pattern that a backend must necessarily provide? __builtin_bswap16 expansion uses the 'rotlhi3' pattern to do a 16 bit bswap as a fallback when there's no 'bswaphi2' pattern in the backend (like on SH at the moment. I haven't added bswaphi2, as __builtin_bswap16 has been working without it). I've just tried disabling the 'rotlhi3' pattern and __builtin_bswap16 expands into shift + and + or (as expected). Thus, I don't think the patch will make something worse (than it already .L42: is) on some backends. If the bswap detection bails out at the tree level, the expanded ops will be shift + and + or -- as written in the original code. So probably, that will be the same as the fallback expansion for __builtin_bswap16, and we're back to sqrt (1). OK, that is what I was asking - are there cases where using rot is worse (like forcing a libcall or so). See also comment in expmed.c (expand_shift_1): It is theoretically possible that the target machine might not be able to perform either shift and hence we would be making two libcalls rather than just the one for the shift (similarly if IOR could not be done). We will allow this extremely unlikely lossage to avoid complicating the code below. */ then goto .L42 ;) Cheers, Oleg
Re: Strenghten early inliner analysis
On Tue, Dec 30, 2014 at 5:21 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.12.30 at 12:37 +0100, Jan Hubicka wrote: Hi, this patch enables inline predicates for early inlining, too. This is easy to do because we do have call stmt around and know if parameters are constants. Bootstrapped/regtested x86_64-linux, comitted. This causes Firefox LTO build on ppc64 to fail: It also caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 -- H.J.
[SH][committed] PR 53987 - Add some known to work tests
Hi,
This adds some known to work SH tests for PR 53987.
Tested with
make -k check-gcc RUNTESTFLAGS=sh.exp=pr53987-1.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
Committed as r219110.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/53987
* gcc.target/sh/pr53987-1.c: New.
Index: gcc/testsuite/gcc.target/sh/pr53987-1.c
===
--- gcc/testsuite/gcc.target/sh/pr53987-1.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr53987-1.c (revision 0)
@@ -0,0 +1,66 @@
+/* Check that no unnecessary sign/zero extensions are being emitted. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* { dg-final { scan-assembler-times extu.b 2 } } */
+/* { dg-final { scan-assembler-not extu.w } } */
+/* { dg-final { scan-assembler-not exts.b } } */
+/* { dg-final { scan-assembler-not exts.w } } */
+/* { dg-final { scan-assembler-not movu } } */
+/* { dg-final { scan-assembler-not tst\t#255 { xfail *-*-*} } } */
+
+int
+test_00 (unsigned char* x, char* xx, int y, int z)
+{
+ /* If x[0] / b is treated as a non-extended QImode subreg the zero
+ test will be a QImode subreg test, which is supposed to ignore
+ bits[31:8]. However, since the QImode memory load always sign
+ extends, it's also OK to test all the bits. Thus we don't want
+ to see a tst #255 here. */
+ int b = x[0];
+ xx[0] = b;
+ return b ? y : z;
+}
+
+int
+test_01 (unsigned char a, unsigned char b, int c, int d)
+{
+ /* 2x extu.b */
+ if (a == b)
+return c;
+ return d;
+}
+
+int
+test_02 (unsigned char* a, unsigned char* b, int c, int d)
+{
+ /* 2x mov.b */
+ if (*a != 0 *b == 0)
+return c;
+ return d;
+}
+
+int
+test_03 (unsigned char* a)
+{
+ /* 1x mov.b */
+ return *a == 0;
+}
+
+int
+test_04 (unsigned short* a)
+{
+ /* 1x mov.w */
+ return *a == 0;
+}
+
+unsigned char test_05_var;
+int
+test_05 (int a, int b, int c, int d)
+{
+ /* Must not see sign/zero extension here. */
+ test_05_var = (a == b) | (b == c);
+ if (test_05_var)
+return d;
+
+ return 0;
+}
Re: [wwwdocs] gcc-5/changes.html: Graphite - CLooG removal; Fortran - update
On 12 November 2014, Tobias Burnus wrote: Hi all, hi Gerald, hi Tobias and Roman, the patch updates gcc-5/changes.html; the Fortran bits are obvious. I have now also committed a patch for Graphite – slightly modified; the Fortran patch has been committed before. Attached is the Graphite part, which I have just committed: https://gcc.gnu.org/gcc-5/changes.html Tobias Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.54 diff -p -u -r1.54 changes.html --- changes.html 26 Dec 2014 15:55:05 - 1.54 +++ changes.html 30 Dec 2014 18:10:31 - @@ -16,6 +16,10 @@ ul liThe default mode for C is now code-std=gnu11/code instead of code-std=gnu89/code./li +liThe Graphite framework for loop optimizations no longer requires the + CLooG library, only ISL version 0.14 (recommended) or 0.12.2. The +installation manual contains more information about requirements to +build GCC./li /ul h2 id=generalGeneral Optimizer Improvements/h2
Re: [PATCH] simplify-rtx: Generalize (and X (ior (not X) Y) - (and X Y)
On Mon, Dec 29, 2014 at 12:14:31PM +, Alan Lawrence wrote: Just a quick thought: will this catch e.g. (and (not X) (ior X Y))? It doesn't (and nothing else does, either; I checked). That's equivalent to (and (not X) (ior (not (not X)) Y)), i.e. (and X' (ior (not X') Y)) with X'=(not X), under the assumption that (not (not X)) is equivalent to X. However I suspect for cases of this form, GET_CODE (XEXP (op1, n)) != NOT...? Right. We'd have to check that in (and A (ior B C)) A is equal to the NOT of B or C. Or, we could transform it to (ior (and A B) (and A C)) and see if that simplifies to something simpler. Also for IOR and AND swapped. Dunno what other cases we miss. I'm a bit worried about the cost of a more general test, and how do you determine what is simpler anyway, in not-so-simple cases. Either way, my patch fixes a testsuite fail ;-) Segher
[SH][committed] Add tst insn test cases
Hi,
This adds some more SH tst insn test cases. Most of them are currently
failing and thus are marked as xfail. I'm working on some patches for
those cases.
Tested with
make -k check-gcc RUNTESTFLAGS=sh.exp=pr49263* --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
Committed as r219111.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/49263
* gcc.target/sh/pr49263-1.c: New.
* gcc.target/sh/pr49263-2.c: New.
[SH][committed] Add tst insn test cases
Hi,
This adds some more SH tst insn test cases. Most of them are currently
failing and thus are marked as xfail. I'm working on some patches for
those cases.
Tested with
make -k check-gcc RUNTESTFLAGS=sh.exp=pr49263* --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
Committed as r219111.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/49263
* gcc.target/sh/pr49263-1.c: New.
* gcc.target/sh/pr49263-2.c: New.
Index: gcc/testsuite/gcc.target/sh/pr49263-1.c
===
--- gcc/testsuite/gcc.target/sh/pr49263-1.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr49263-1.c (revision 0)
@@ -0,0 +1,62 @@
+/* Verify that TST #imm, R0 instruction is generated when QImode or HImode
+ values are tested against a negative constant. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* { dg-final { scan-assembler-not and } } */
+/* { dg-final { scan-assembler-not bclr { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times extu 1 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times exts 1 { xfail *-*-* } } } */
+
+#define make_func(__valtype__, __valget__, __tstval__, __suff__)\
+ int test_imm_##__tstval__##__suff__ (__valtype__ val) \
+{\
+ return ((__valget__) (- 0x##__tstval__ 0)) ? -20 : -40;\
+}
+
+#define make_func_0_F(__valtype__, __valget__, __y__, __suff__)\
+ make_func (__valtype__, __valget__, __y__##0, __suff__)\
+ make_func (__valtype__, __valget__, __y__##1, __suff__)\
+ make_func (__valtype__, __valget__, __y__##2, __suff__)\
+ make_func (__valtype__, __valget__, __y__##3, __suff__)\
+ make_func (__valtype__, __valget__, __y__##4, __suff__)\
+ make_func (__valtype__, __valget__, __y__##5, __suff__)\
+ make_func (__valtype__, __valget__, __y__##6, __suff__)\
+ make_func (__valtype__, __valget__, __y__##7, __suff__)\
+ make_func (__valtype__, __valget__, __y__##8, __suff__)\
+ make_func (__valtype__, __valget__, __y__##9, __suff__)\
+ make_func (__valtype__, __valget__, __y__##A, __suff__)\
+ make_func (__valtype__, __valget__, __y__##B, __suff__)\
+ make_func (__valtype__, __valget__, __y__##C, __suff__)\
+ make_func (__valtype__, __valget__, __y__##D, __suff__)\
+ make_func (__valtype__, __valget__, __y__##E, __suff__)\
+ make_func (__valtype__, __valget__, __y__##F, __suff__)\
+
+#define make_funcs_0_FF(__valtype__, __valget__, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 0, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 1, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 2, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 3, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 4, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 5, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 6, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 7, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 8, __suff__)\
+ make_func_0_F (__valtype__, __valget__, 9, __suff__)\
+ make_func_0_F (__valtype__, __valget__, A, __suff__)\
+ make_func_0_F (__valtype__, __valget__, B, __suff__)\
+ make_func_0_F (__valtype__, __valget__, C, __suff__)\
+ make_func_0_F (__valtype__, __valget__, D, __suff__)\
+ make_func_0_F (__valtype__, __valget__, E, __suff__)\
+ make_func_0_F (__valtype__, __valget__, F, __suff__)\
+
+make_funcs_0_FF (signed char*, *val, int8_mem)
+make_funcs_0_FF (signed char, val, int8_reg)
+
+make_funcs_0_FF (unsigned char*, *val, uint8_mem)
+make_funcs_0_FF (unsigned char, val, uint8_reg)
+
+make_funcs_0_FF (short*, *val, int16_mem)
+make_funcs_0_FF (short, val, int16_reg)
+
+make_funcs_0_FF (unsigned short*, *val, uint16_mem)
+make_funcs_0_FF (unsigned short, val, uint16_reg)
Index: gcc/testsuite/gcc.target/sh/pr49263-2.c
===
--- gcc/testsuite/gcc.target/sh/pr49263-2.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr49263-2.c (revision 0)
@@ -0,0 +1,54 @@
+/* Verify that TST #imm, R0 instruction is generated when QImode or HImode
+ values are tested against a negative constant. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* { dg-final { scan-assembler-not and } } */
+/* { dg-final { scan-assembler-not exts { xfail *-*-* } } } */
+
+/* { dg-final { scan-assembler-times tst\t#127,r0 2 } } */
+/* { dg-final { scan-assembler-times tst\t#255,r0 1 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times 65407 1 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times -129 2 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times extu 1 { xfail *-*-* } } } */
+
+int
+test_00 (unsigned char x)
+{
+ /* 1x tst #127 */
+ return x -129 ? -20 : -40;
+}
+
+int
+test_01 (signed char x)
+{
+ /* 1x tst #255 */
+ return x -129 ? -20 : -40;
+}
+
+int
+test_02 (unsigned short x)
+{
+ /* 1x tst 65407 */
+ return x -129 ? -20 : -40;
+}
+
+int
+test_03 (unsigned short* x)
+{
+ /* 1x tst -129 */
+ return
[SH][committed] Add tst/bld insn test cases
Hi,
This adds some more SH tst and SH2A bld insn test cases. Most of them
are currently failing and thus are marked as xfail. I'm working on some
patches for those cases.
Tested with
make -k check-gcc RUNTESTFLAGS=sh.exp=pr49263* --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
Committed as r219113.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/49263
* gcc.target/sh/sh.exp (check_effective_target_sh2a): New.
* gcc.target/sh/pr49263-3.c: New.
Index: gcc/testsuite/gcc.target/sh/sh.exp
===
--- gcc/testsuite/gcc.target/sh/sh.exp (revision 219111)
+++ gcc/testsuite/gcc.target/sh/sh.exp (working copy)
@@ -24,6 +24,15 @@
# Load support procs.
load_lib gcc-dg.exp
+# Return 1 if target is SH2A
+proc check_effective_target_sh2a { } {
+return [check_no_compiler_messages sh2a object {
+ #ifndef __SH2A__
+ #error
+ #endif
+} ]
+}
+
# If a testcase doesn't have special options, use these.
global DEFAULT_CFLAGS
if ![info exists DEFAULT_CFLAGS] then {
Index: gcc/testsuite/gcc.target/sh/pr49263-3.c
===
--- gcc/testsuite/gcc.target/sh/pr49263-3.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr49263-3.c (revision 0)
@@ -0,0 +1,176 @@
+/* Verify that TST #imm, R0 instruction is generated when the tested reg
+ is shifted by a constant amount. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* { dg-final { scan-assembler-not and|shl|sha|exts { xfail *-*-* } } } */
+
+/* { dg-final { scan-assembler-times tst\t#7,r0 3 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times tst\t#12,r0 1 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times tst\t#24,r0 6 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times tst\t#13,r0 3 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times tst\t#242,r0 3 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times tst\t#252,r0 1 } } */
+
+/* { dg-final { scan-assembler-times tst\t#64,r0 6 { target { ! sh2a } xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times tst\t#64,r0 4 { target { sh2a } xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times bld\t#6 2 { target { sh2a } xfail *-*-* } } } */
+
+int
+test_00 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #12 */
+ return (x[0] 4) 192 ? y : z;
+}
+
+int
+test_01 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #24 */
+ return (x[0] 3) 192 ? y : z;
+}
+
+int
+test_02 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #24 */
+ return ((x[0] 3) 192) != 0;
+}
+
+int
+test_03 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #24 */
+ return ((x[0] 3) 192) == 0;
+}
+
+int
+test_04 (unsigned char x, int y, int z)
+{
+ /* 1x tst #24 */
+ return (x 3) 192 ? y : z;
+}
+
+int
+test_05 (unsigned char x, int y, int z)
+{
+ /* 1x tst #24 */
+ return ((x 3) 192) != 0;
+}
+
+int
+test_06 (unsigned char x, int y, int z)
+{
+ /* 1x tst #24 */
+ return ((x 3) 192) == 0;
+}
+
+int
+test_07 (unsigned char x, int y, int z)
+{
+ /* 1x tst #13 */
+ return (x 3) 111 ? y : z;
+}
+
+int
+test_08 (unsigned char x, int y, int z)
+{
+ /* 1x tst #13 */
+ return ((x 3) 111) != 0;
+}
+
+int
+test_09 (unsigned char x, int y, int z)
+{
+ /* 1x tst #13 */
+ return ((x 3) 111) == 0;
+}
+
+int
+test_10 (unsigned char x, int y, int z)
+{
+ /* 1x tst #242 */
+ return (x 3) -111 ? y : z;
+}
+
+int
+test_11 (unsigned char x, int y, int z)
+{
+ /* 1x tst #242 */
+ return ((x 3) -111) != 0;
+}
+
+int
+test_12 (unsigned char x, int y, int z)
+{
+ /* 1x tst #242 */
+ return ((x 3) -111) == 0;
+}
+
+int
+test_13 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #64 */
+ return (x[0] 2) 16 ? y : z;
+}
+
+int
+test_14 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #64 / 1x bld #6*/
+ return ((x[0] 2) 16) != 0;
+}
+int
+test_15 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #64 */
+ return ((x[0] 2) 16) == 0;
+}
+
+int
+test_16 (unsigned char x, int y, int z)
+{
+ /* 1x tst #64 */
+ return (x 2) 16 ? y : z;
+}
+
+int
+test_17 (unsigned char x, int y, int z)
+{
+ /* 1x tst #64 / 1x bld #6*/
+ return ((x 2) 16) != 0;
+}
+
+int
+test_18 (unsigned char x, int y, int z)
+{
+ /* 1x tst #64 */
+ return ((x 2) 16) == 0;
+}
+
+int
+test_19 (signed char x, int y, int z)
+{
+ /* 1x tst #7 */
+ return (x 1) 0x0F ? y : z;
+}
+
+int
+test_20 (signed char x, int y, int z)
+{
+ /* 1x tst #7 */
+ return ((x 1) 0x0F) != 0;
+}
+
+int
+test_21 (signed char x, int y, int z)
+{
+ /* 1x tst #7 */
+ return ((x 1) 0x0F) == 0;
+}
+
+int
+test_22 (unsigned char* x, int y, int z)
+{
+ /* 1x tst #252 */
+ return (x[0] 2) ? y : z;
+}
[PATCH, libgo] Backport for PPC64 reloc fix to 4.9
Hi,
The following should have been included with the backport for 4.9 in
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01383.html to allow the
debuginfo to be read for EM_PPC64.
2014-12-30 Lynn Boger labo...@linux.vnet.ibm.com
* libgo/go/debug/elf/file.go: Read debug_info for EM_PPC64
Index: libgo/go/debug/elf/file.go
===
--- libgo/go/debug/elf/file.go (revision 218817)
+++ libgo/go/debug/elf/file.go (working copy)
@@ -681,7 +681,7 @@ func (f *File) DWARF() (*dwarf.Data, error) {
// If there's a relocation table for .debug_info, we have to process it
// now otherwise the data in .debug_info is invalid for x86-64 objects.
rela := f.Section(.rela.debug_info)
- if rela != nil rela.Type == SHT_RELA (f.Machine == EM_X86_64 ||
f.Machine == EM_AARCH64) {
+ if rela != nil rela.Type == SHT_RELA (f.Machine == EM_X86_64 ||
f.Machine == EM_AARCH64 || f.Machine == EM_PPC64) {
data, err := rela.Data()
if err != nil {
return nil, err
[PATCH, libgo] Backport for handling of 64 bit symbol tables in gccgo
Hi,
Please backport the following fix to the gcc 4.9 branch.
2014-12-30 Lynn Boger labo...@linux.vnet.ibm.com
* gcc/go/gofrontend/import-archive.cc: Recognize 64-bit symbol tables
Index: gcc/go/gofrontend/import-archive.cc
===
--- gcc/go/gofrontend/import-archive.cc (revision 218817)
+++ gcc/go/gofrontend/import-archive.cc (working copy)
@@ -295,6 +295,15 @@ Archive_file::interpret_header(const Archive_heade
// This is the symbol table.
pname-clear();
}
+ else if (hdr-ar_name[1] == 'S' hdr-ar_name[2] == 'Y'
+ hdr-ar_name[3] == 'M' hdr-ar_name[4] == '6'
+ hdr-ar_name[5] == '4' hdr-ar_name[6] == '/'
+ hdr-ar_name[7] == ' '
+ )
+{
+ // 64-bit symbol table.
+ pname-clear();
+}
else if (hdr-ar_name[1] == '/')
{
// This is the extended name table.
[PATCH, libgo] Backport to gcc 4.9 GOARCH setting for ppc64le
Hi,
Please backport this change to the gcc 4.9 branch so that the GOARCH
value setting for ppc64le is consistent with trunk.
This has been bootstrapped and regression tested on ppc64le and ppc64
(along with the other patches submitted for the
4.9 branch today).
2014-12-30 Lynn Boger labo...@linux.vnet.ibm.com
* gcc/testsuite/go.test/go-test.exp: Recognize goarch value pp64le
* libgo/configure.ac: Set GOARCH ppc64le where appropriate
* libgo/go/go/build/syslist.go: Add ppc64le to the goarchList
* libgo/configure: regenerate
Index: gcc/testsuite/go.test/go-test.exp
===
--- gcc/testsuite/go.test/go-test.exp (revision 218817)
+++ gcc/testsuite/go.test/go-test.exp (working copy)
@@ -241,7 +241,11 @@ proc go-set-goarch { } {
if [check_effective_target_ilp32] {
set goarch ppc
} else {
- set goarch ppc64
+ if [istarget powerpc64le-*-*] {
+ set goarch ppc64le
+ } else {
+ set goarch ppc64
+ }
}
}
sparc*-*-* {
Index: libgo/configure.ac
===
--- libgo/configure.ac (revision 218817)
+++ libgo/configure.ac (working copy)
@@ -179,6 +179,7 @@ is_m68k=no
mips_abi=unknown
is_ppc=no
is_ppc64=no
+is_ppc64le=no
is_sparc=no
is_sparc64=no
is_x86_64=no
@@ -249,11 +250,18 @@ changequote([,])dnl
#ifdef _ARCH_PPC64
#error 64-bit
#endif],
-[is_ppc=yes], [is_ppc64=yes])
+[is_ppc=yes],
+[AC_COMPILE_IFELSE([
+#if defined(_BIG_ENDIAN) || defined(__BIG_ENDIAN__)
+#error 64be
+#endif],
+[is_ppc64le=yes],[is_ppc64=yes])])
if test $is_ppc = yes; then
GOARCH=ppc
+elif test $is_ppc64 = yes; then
+ GOARCH=ppc64
else
- GOARCH=ppc64
+ GOARCH=ppc64le
fi
;;
sparc*-*-*)
@@ -281,6 +289,7 @@ AM_CONDITIONAL(LIBGO_IS_MIPSN64, test $mips_abi =
AM_CONDITIONAL(LIBGO_IS_MIPSO64, test $mips_abi = o64)
AM_CONDITIONAL(LIBGO_IS_PPC, test $is_ppc = yes)
AM_CONDITIONAL(LIBGO_IS_PPC64, test $is_ppc64 = yes)
+AM_CONDITIONAL(LIBGO_IS_PPC64LE, test $is_ppc64le = yes)
AM_CONDITIONAL(LIBGO_IS_SPARC, test $is_sparc = yes)
AM_CONDITIONAL(LIBGO_IS_SPARC64, test $is_sparc64 = yes)
AM_CONDITIONAL(LIBGO_IS_X86_64, test $is_x86_64 = yes)
Index: libgo/go/go/build/syslist.go
===
--- libgo/go/go/build/syslist.go (revision 218817)
+++ libgo/go/go/build/syslist.go (working copy)
@@ -5,4 +5,4 @@
package build
const goosList = darwin dragonfly freebsd linux netbsd openbsd plan9 windows solaris
-const goarchList = 386 amd64 arm arm64 alpha m68k mipso32 mipsn32 mipsn64 mipso64 ppc ppc64 sparc sparc64
+const goarchList = 386 amd64 arm arm64 alpha m68k mipso32 mipsn32 mipsn64 mipso64 ppc ppc64 ppc64le sparc sparc64
[PATCH, libgo] Backport fix for compiler flags in mksysinfo.sh to gcc 4.9
Hi,
Please backport the change from
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00713.html to gcc 4.9.
2014-12-30 Lynn Boger labo...@linux.vnet.ibm.com
* libgo/mksysinfo.sh: Add the same compiler flags used by
configure to detect whether off64_t is present
when generating the go structures for C types. Otherwise the go
type for off64_t might not be
generated.
Index: libgo/mksysinfo.sh
===
--- libgo/mksysinfo.sh (revision 218817)
+++ libgo/mksysinfo.sh (working copy)
@@ -204,8 +204,10 @@ enum {
};
EOF
-${CC} -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S -o sysinfo.s sysinfo.c
+${CC} -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \
+ -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S -o sysinfo.s sysinfo.c
+
echo 'package syscall' ${OUT}
echo 'import unsafe' ${OUT}
echo 'type _ unsafe.Pointer' ${OUT}
[PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
fredag 14 november 2014 23.31.48 skrev Magnus Granberg:
måndag 10 november 2014 21.26.39 skrev Magnus Granberg:
Rainer
Thanks Rainer for the nits and comments.
Have updated the patches and Changelogs.
But i still use PIE_DRIVER_SELF_SPECS, do you have a ide where move it so
i don't need to duplicate that stuff or how to do it?
Magnus G
2014-11-10 Magnus Granberg zo...@gentoo.org
/gcc
* config/gnu-user.h (PIE_DRIVER_SELF_SPECS) and
(GNU_DRIVER_SELF_SPECS): Define.
* config/i386/gnu-user-common.h (DRIVER_SELF_SPECS): Define
* configure.ac: Add new option.
* configure, config.in: Rebuild.
* Makefile.in (ALL_CFLAGS) and (ALL_CXXFLAGS): Disable PIE.
* doc/install.texi: New configure option.
* doc/invoke.texi: Add note to PIE.
* doc/sourcebuild.texi: New effective target.
gcc/testsuite
* gcc/default-pie.c: New test
* gcc.dg/tree-ssa/ssa-store-ccp-3.c: Skip if default_pie
* g++.dg/other/anon5.C: Skip if default_pie
* lib/target-supports.exp (check_effective_target_default_pie):
New proc.
/libgcc
* Makefile.in (CRTSTUFF_CFLAGS): Disable PIE.
Can this be included for GCC 5 ?
/Magnus G.
One more ping on this. The patches where sent before stage 1 closed but i
did't get any feed back from it
Have updete the patchses for gcc 5.0 20141228 snapshot.
Bootstrapped and tested on x86_64-unknown-linux-gnu (Gentoo)
/Magnus
2014-12-30 Magnus Granberg zo...@gentoo.org
/gcc
* config/gnu-user.h (PIE_DRIVER_SELF_SPECS): Define.
* config/i386/gnu-user-common.h (DRIVER_SELF_SPECS): Define and
add PIE_DRIVER_SELF_SPECS.
* configure.ac: Add new option.
* configure, config.in: Rebuild.
* Makefile.in (ALL_CFLAGS) and (ALL_CXXFLAGS): Disable PIE.
* doc/install.texi: New configure option.
* doc/invoke.texi: Add note to PIE.
* doc/sourcebuild.texi: New effective target.
gcc/testsuite
* gcc/default-pie.c: New test
* gcc.dg/tree-ssa/ssa-store-ccp-3.c: Skip if default_pie
* g++.dg/other/anon5.C: Skip if default_pie
* lib/target-supports.exp (check_effective_target_default_pie):
New proc.
/libgcc
* Makefile.in (CRTSTUFF_CFLAGS): Disable PIE.
--- a/gcc/doc/install.texi 2013-10-01 19:29:40.0 +0200
+++ b/gcc/doc/install.texi 2013-11-17 16:13:20.474144921 +0100
@@ -1583,6 +1583,10 @@ do a @samp{make -C gcc gnatlib_and_tools
Specify that the run-time libraries for stack smashing protection
should not be built.
+@item --enable-default-pie
+Turn on @option{-fPIE} and @option{-pie} by default if supported.
+Currently supported targets are i?86-*-linux* and x86-64-*-linux*.
+
@item --disable-libquadmath
Specify that the GCC quad-precision math library should not be built.
On some systems, the library is required to be linkable when building
--- a/gcc/doc/invoke.texi 2013-10-03 19:13:50.0 +0200
+++ b/gcc/doc/invoke.texi 2013-11-17 21:30:02.784220111 +0100
@@ -10898,6 +10898,13 @@ For predictable results, you must also s
used for compilation (@option{-fpie}, @option{-fPIE},
or model suboptions) when you specify this linker option.
+@emph{Note}: With the @option{--enable-default-pie} configure option, this
+options is enabled by default for C, C++, ObjC, ObjC++, if none of
+@option{-fno-PIE}, @option{-fno-pie}, @option{-fPIC}, @option{-fpic},
+@option{-fno-PIC}, @option{-fno-pic}, @option{-nostdlib},
+@option{-nostartfiles}, @option{-shared}, @option{-nodefaultlibs},
+nor @option{-static} are found.
+
@item -rdynamic
@opindex rdynamic
Pass the flag @option{-export-dynamic} to the ELF linker, on targets
@@ -23071,6 +23071,13 @@ used during linking.
@code{__pie__} and @code{__PIE__}. The macros have the value 1
for @option{-fpie} and 2 for @option{-fPIE}.
+@emph{Note}: With the @option{--enable-default-pie} configure option, this
+options is enabled by default for C, C++, ObjC, ObjC++, if none of
+@option{-fno-PIE}, @option{-fno-pie}, @option{-fPIC}, @option{-fpic},
+@option{-fno-PIC}, @option{-fno-pic}, @option{-nostdlib},
+@option{-nostartfiles}, @option{-shared}, @option{-nodefaultlibs},
+nor @option{-static} are found.
+
@item -fno-jump-tables
@opindex fno-jump-tables
Do not use jump tables for switch statements even where it would be
--- a/gcc/doc/sourcebuild.texi 2014-08-20 17:56:45.0 +0200
+++ b/gcc/doc/sourcebuild.texi 2014-11-09 23:43:06.254817553 +0100
@@ -1890,6 +1890,9 @@ Target supports @option{-mpe-aligned-com
@item pie
Target supports @option{-pie}, @option{-fpie} and @option{-fPIE}.
+@item default_pie
+Target enable @option{-pie}, and @option{-fPIE} as default.
+
@item section_anchors
Target supports section anchors.
--- a/gcc/config/gnu-user.h 2013-08-20 10:31:40.0 +0200
+++ b/gcc/config/gnu-user.h 2013-10-23 22:01:42.337238981 +0200
@@ -131,3 +131,13 @@ see the files COPYING3 and COPYING.RUNTI
Re: Strenghten early inliner analysis
Hi,
the problem is that we free node params when early analysis is called late
via add_new_function.
Bootstrapped/regtsted x86_64-linux, comitted.
Honza
2014-12-30 Jan Hubicka hubi...@ucw.cz
* ipa-inline-analysis.c (estimate_function_body_sizes): Do not
free node params when called late with early=true.
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 219108)
+++ ipa-inline-analysis.c (working copy)
@@ -2851,7 +2851,7 @@ estimate_function_body_sizes (struct cgr
{
if (!early)
loop_optimizer_finalize ();
- else
+ else if (!ipa_edge_args_vector)
ipa_free_all_node_params ();
free_dominance_info (CDI_DOMINATORS);
}
Re: [PATCH] toplev.c: Process the failure when read fails for random_seed
On Mon, 29 Dec 2014, Chen Gang S wrote: 2014-12-27 Chen Gang gang.chen.5...@gmail.com * toplev.c (init_local_tick): Process the failure when read fails for random_seed. OK. -- Joseph S. Myers jos...@codesourcery.com
