[libstdc++ PATCH] Add support for std::uncaught_exceptions
The patch is a bit large since it does the baseline_symbols regeneration and other new-version api-dance. Hence attached gzipped. Tested on Linux x86-64. 2015-04-13 Ville Voutilainen ville.voutilai...@gmail.com Add support for std::uncaught_exceptions. * acinclude.m4: Bump libtool_VERSION. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/pre/gnu.ver: Export the new symbol. * configure: Bump libtool_VERSION. * libsupc++/eh_catch.cc(uncaught_exceptions): New. * libsupc++/exception(uncaught_exceptions): Ditto. * testsuite/18_support/uncaught_exceptions/uncaught_exceptions.cc: New. * testsuite/util/testsuite_abi.cc: Add 3.4.22 as the latest version. uncaught_exceptions.diff.gz Description: GNU Zip compressed data
Re: [PATCH][wwwdocs] Update 5.0 changes.html with Thumb1 UAL
On Sat, Apr 11, 2015 at 5:48 AM, Gerald Pfeifer ger...@pfeifer.com wrote: Hi Terry, I went ahead and committed some small changes to the description of -masm-syntax-unified. Let me know if you disagree or would like to see further changes. Gerald Thanks for the improvement. I am totally ok with them. BR, Terry Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.101 diff -u -r1.101 changes.html --- changes.html9 Apr 2015 23:30:47 - 1.101 +++ changes.html10 Apr 2015 21:47:01 - @@ -636,8 +636,8 @@ h3 id=armARM/h3 ul - li The Thumb-1 assembly code is now generated in unified syntax. The new option -code-masm-syntax-unified/code can be used to specify whether inline assembly + liThumb-1 assembly code is now generated in unified syntax. The new option +code-masm-syntax-unified/code specifies whether inline assembly code is using unified syntax. By default the option is off which means non-unified syntax is used. However this is subject to change in future releases. Eventually the non-unified syntax will be deprecated.
patch fix issue 1 with [libstdc++/65033] Give alignment info to libatomic
PR libstdc++/62259
PR libstdc++/65147
* include/std/atomic (atomicT): Increase alignment for types with
the same size as one of the integral types.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error line number.
* testsuite/29_atomics/atomic/62259.cc: New.
Ever since aligmnent was made sane-ish, 62259.cc has failed for
reasons obvious in the patch. Can I please commit this?
* testsuite/29_atomics/atomic/62259.cc: Assert atomic
alignment is larger-equal, not equal, to default alignment.
Index: libstdc++-v3/testsuite/29_atomics/atomic/62259.cc
===
--- libstdc++-v3/testsuite/29_atomics/atomic/62259.cc (revision 222036)
+++ libstdc++-v3/testsuite/29_atomics/atomic/62259.cc (working copy)
@@ -33,7 +33,7 @@ struct twoints {
int32_t b;
};
-static_assert( alignof(std::atomictwoints) == alignof(int64_t),
+static_assert( alignof(std::atomictwoints) = alignof(int64_t),
std::atomic not suitably aligned );
// libstdc++/65147
@@ -44,7 +44,7 @@ struct power_of_two_obj {
std::atomicpower_of_two_obj obj1;
-static_assert( alignof(obj1) == alignof(int64_t),
+static_assert( alignof(obj1) = alignof(int64_t),
std::atomic not suitably aligned );
struct container_struct {
@@ -54,5 +54,5 @@ struct container_struct {
container_struct obj2;
-static_assert( alignof(obj2.ao) == alignof(int64_t),
+static_assert( alignof(obj2.ao) = alignof(int64_t),
std::atomic not suitably aligned );
brgds, H-P
RE: [PATCH] Fix bdverN vector cost of cond_[not_]taken_branch_cost
Note that before the fixes for PR64909 the epilogue/prologue loops had very large costs associated due to a bug in the cost model implementation. After the fix their cost is reasonable but the cost of the extra jumps is way under-accounted for due to the numbers for cond_taken_branch_cost and cond_not_taken_branch_cost. The proposes match mitigates that somewhat. Richard! The patch is good. We are done with our benchmarking and found no regressions. How did you arrive at the original cost model? The original cost model as you suspect is not based on architecture alone. Those are the numbers arrived at by analyzing benchmarks and the cost model bugs then. These initial numbers were copied for subsequent architectures too. Cost assignments saying scalar_stmt_cost = 6 and scalar load_cost = 4 doesn't make sense at all. We will have a look into it. Regards Ganesh -Original Message- From: Richard Biener [mailto:rguent...@suse.de] Sent: Wednesday, April 08, 2015 1:08 PM To: Gopalasubramanian, Ganesh Cc: Uros Bizjak; gcc-patches@gcc.gnu.org Subject: RE: [PATCH] Fix bdverN vector cost of cond_[not_]taken_branch_cost On Wed, 8 Apr 2015, Gopalasubramanian, Ganesh wrote: I have added a person from AMD to comment on the decision. Otherwise, the patch looks OK, but please wait a couple of days for possible comments. Thank you Uros! I am checking the changes with few tests and benchmarking them. Please wait for a couple of days. Note that before the fixes for PR64909 the epilogue/prologue loops had very large costs associated due to a bug in the cost model implementation. After the fix their cost is reasonable but the cost of the extra jumps is way under-accounted for due to the numbers for cond_taken_branch_cost and cond_not_taken_branch_cost. The proposes match mitigates that somewhat. How did you arrive at the original cost model? Thanks, Richard. -- Richard Biener rguent...@suse.de SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
Re: [PING, AArch64] Add long-call attribute and pragma interfaces
On 04/02/2015 11:59 PM, Yangfei (Felix) wrote: Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01148.html This patch needs documentation for the new attributes and pragmas before it can be committed. (Since this is a new feature I think it has to wait until stage 1, too, but that's not my call.) -Sandra Sure, I will update the docs when this patch is approved by the port maintainers. I didn't get any feedback from Richard for the v2 patch. Thanks.
Re: Fix for PRs 36043, 58744 and 65408
On Wed, Mar 18, 2015 at 12:12:17PM +0100, Richard Biener wrote:
On Wed, Mar 18, 2015 at 5:22 AM, Alan Modra amo...@gmail.com wrote:
On Tue, Mar 17, 2015 at 01:28:41PM -0600, Jeff Law wrote:
On 03/14/2015 07:02 AM, Alan Modra wrote:
PR target/65408
PR target/58744
PR middle-end/36043
* calls.c (load_register_parameters): Don't load past end of
mem unless suitably aligned.
I think this is probably a stage1 item. Richi, Jakub, Joseph, do any of
you
think we should try to push this into gcc-5?
Some (severity) background to PR65408. The bug came from SAP HANA
(en.wikipedia.org/wiki/SAP_HANA), a crash that happens on powerpc64
and powerpc64le. aarch64 would also be susceptible to the crash since
it also loads 16 bytes for the 12-byte struct. x86_64 only loads 12
bytes (i386.c:construct_container generates a parallel with a DImode
and SImode load). However the underlying bug is there and hits x86_64
too for the pr58744 and pr36043 testcases..
It's a very very very old bug though. I'd be interested in any odd
code-generation difference for compiling, say, the linux kernel
(you _can_ get quite ugly code generated because of this fix).
Yes, all those byte loads.. As far as the kernel goes, x86_64 shows
some differences in calls to rgb_{fore,back}ground in
drivers/tty/vt/vt.c. Both before and after look ugly to me. :)
4d73: 8b 82 24 02 00 00 mov0x224(%rdx),%eax
4d79: 48 89 dfmov%rbx,%rdi
4d7c: 41 83 c4 04 add$0x4,%r12d
4d80: 88 45 b2mov%al,-0x4e(%rbp)
4d83: 8b 82 28 02 00 00 mov0x228(%rdx),%eax
4d89: 88 45 b3mov%al,-0x4d(%rbp)
4d8c: 8b 82 2c 02 00 00 mov0x22c(%rdx),%eax
4d92: 88 45 b4mov%al,-0x4c(%rbp)
4d95: 48 8b 75 b2 mov-0x4e(%rbp),%rsi
4d99: e8 00 00 00 00 callq rgb_background
vs.
4d73: 8b 82 24 02 00 00 mov0x224(%rdx),%eax
4d79: 0f b6 b2 2c 02 00 00movzbl 0x22c(%rdx),%esi
4d80: 48 89 dfmov%rbx,%rdi
4d83: 41 83 c4 04 add$0x4,%r12d
4d87: 88 45 b2mov%al,-0x4e(%rbp)
4d8a: 8b 82 28 02 00 00 mov0x228(%rdx),%eax
4d90: 48 c1 e6 10 shl$0x10,%rsi
4d94: 88 45 b3mov%al,-0x4d(%rbp)
4d97: 0f b7 45 b2 movzwl -0x4e(%rbp),%eax
4d9b: 48 09 c6or %rax,%rsi
4d9e: e8 00 00 00 00 callq rgb_background
Is the patch OK for stage1?
--
Alan Modra
Australia Development Lab, IBM
RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0
On Thu, 5 Feb 2015, Matthew Fortune wrote: Thanks Catherine. Good call to remove the markup while reviewing. I've done one more pass on this to have the same phrasing used where similar points are being made. I also added a comment about link compatibility for FP64. Updated text is at the end. Here are some more changes on top of the version that was committed. Add an article, add markup, simplify language, and use 64-bit instead of 64-bits in the MIPS section. (has been changed - has changed, is being used - is used, and there are one or two others which I left since I wasn't sure.) I applied this now, though if there is anything you disagree with we can always revisit. Just advise! Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.104 diff -u -r1.104 changes.html --- changes.html12 Apr 2015 20:26:50 - 1.104 +++ changes.html12 Apr 2015 21:32:20 - @@ -739,13 +739,13 @@ code-march=p5600/code command-line option./li liThe Cavium Octeon3 processor is now supported using the code-march=octeon3/code command-line option./li -liMIPS Release 6 is now supported using code-mips32r6/code and - code-mips64r6/code command-line options./li +liMIPS Release 6 is now supported using the code-mips32r6/code + and code-mips64r6/code command-line options./li liThe o32 ABI has been modified and extended. The o32 64-bit floating-point register support is now obsolete and has been removed. It has been replaced by three ABI extensions FPXX, FP64A, and FP64. - The meaning of the code-mfp64/code command-line option has been - changed and it is now used to enable the FP64A and FP64 ABI extensions. + The meaning of the code-mfp64/code command-line option has + changed. It is now used to enable the FP64A and FP64 ABI extensions. ul liThe FPXX extension requires that code generated to access double-precision values use even-numbered registers. Code that @@ -755,14 +755,14 @@ -mfpxx/code can be used to enable this extension. MIPS II is the minimum processor required./li liThe o32 FP64A extension requires that floating-point registers be - 64-bits and odd-numbered single-precision registers are not + 64-bit and odd-numbered single-precision registers are not allowed. Code that adheres to the o32 FP64A variant is link-compatible with all other o32 double-precision ABI variants. The command-line options code-mabi=32 -mfp64 -mno-odd-spreg /code can be used to enable this extension. MIPS32R2 is the minimum processor required./li liThe o32 FP64 extension also requires that floating-point registers - be 64-bits, but permits the use of single-precision registers. + be 64-bit, but permits the use of single-precision registers. Code that adheres to the o32 FP64 variant is link-compatible with o32 FPXX and o32 FP64A variants only, i.e. it is not compatible with the original o32 double-precision ABI. The command-line @@ -777,10 +777,10 @@ required to run the generated code on MIPSR5 cores in conjunction with future MIPS SIMD (MSA) code and MIPSR6 cores./li liGCC will now pass all floating-point options to the assembler if GNU - binutils 2.25 is being used. As a result, any inline assembly code that - uses hard-float instructions should be amended to include a .set - directive to override the global assembler options when compiling for - soft-float targets./li + binutils 2.25 is used. As a result, any inline assembly code that + uses hard-float instructions should be amended to include a + code.set/code directive to override the global assembler options + when compiling for soft-float targets./li /ul h3 id=nds32NDS32/h3
Re: [wwwdocs] 4.9/changes.html: Mention -Wopenmp-simd/-fsimd-cost-model; Fortran update
[ Tobias, your bur...@net-b.de account just bounced with mailbox full! ] On Tue, 18 Feb 2014, Tobias Burnus wrote: is the wording okay - and/or do you have further suggestions? Here are some suggestions on top of the existing text. Remove a comma and break a long sentence in the SIMD section. Use least significant instead of last significant when refering to rounding and simplify a sentence in the Fortran section. I have not committed this yet since the sentence on rounding really feels rather weird. Should there be something like whereas compatible would round... (as opposed to rounds)? Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.85 diff -u -r1.85 changes.html --- changes.html8 Apr 2015 10:33:06 - 1.85 +++ changes.html12 Apr 2015 21:47:26 - @@ -127,11 +127,11 @@ OpenMP specification/a is now supported in the C and C++ compilers and starting with the 4.9.1 release also in the Fortran compiler. The new code-fopenmp-simd/code option can be used to enable OpenMP's - SIMD directives, while ignoring other OpenMP directives. The new a + SIMD directives while ignoring other OpenMP directives. The new a href=https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html#index-fsimd-cost-model-908; code-fsimd-cost-model=/code/a option permits to tune the vectorization cost model for loops annotated with OpenMP and Cilk - Plus codesimd/code directives; code-Wopenmp-simd/code warns when + Plus codesimd/code directives. code-Wopenmp-simd/code warns when the current cost model overrides simd directives set by the user./li liThe code-Wdate-time/code option has been added for the C, C++ and Fortran compilers, which warns when the code__DATE__/code, @@ -459,9 +459,9 @@ codestrtod/code honours the rounding mode. (For output, rounding is supported since GCC 4.5.) Note that for input, the codecompatible/code rounding mode is handled as codenearest/code -(i.e., for a tie, rounding to an even last significant -[cf. IEC 60559:1989] ndash; while codecompatible/code rounds away -from zero for a tie)./li +(i.e., rounding to an even least significant [cf. IEC 60559:1989] +for a tie, while codecompatible/code rounds away from zero in +that case)./li /ul/li /ul
Re: Mention of gcc 4.5 as first version with plugin support
On Mon, 14 Jan 2013, Dave Johansen wrote: +GCC plugin support is available in GCC version 4.5.0 and +later. What's the value of documenting the availability of an unstable API in older versions of GCC? Mind this documentation is version specific. Richard. My point wasn't to encourage people to use 4.5 for plugins, but just to state when it became available. I was looking into enabling/installing plugin support on RHEL 5/6 and spent several hours trying to figure out why it wasn't available only to later find out that it wasn't available in gcc 4.4. I considered this again and again, and while I understand the unfortunate situation you ran into with the old system compiler on older versions of your OS, I am tempted to side with Richard -- and GCC plugins really make (more) sense with reasonably current versions of GCC, so by identifying GCC 4.5 we might set wrong expectations. Gerald
New Serbian PO file for 'cpplib' (version 5.1-b20150208)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Serbian team of translators. The file is available at: http://translationproject.org/latest/cpplib/sr.po (This file, 'cpplib-5.1-b20150208.sr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Contents of PO file 'cpplib-5.1-b20150208.sr.po'
cpplib-5.1-b20150208.sr.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [wwwdocs] gcc-4.8/porting_to.html
On Wed, 13 Mar 2013, Benjamin De Kosnik wrote: Hey! Here is the first pass at the 4.8 porting documentation. Lovely, thank you, I know this really has proven useful. And with some unfortunate of delay, some updates from my side: - Use run-time performance (instead of runtime performance which Sandra established as the performance of the runtime, I think). - Code does not use warning options per se. - Undefined behavior is undefined regardless of how involved optimizers are. - Improve markup, fix grammar, break long lines. - Refer to GNU/Linux. Applied. Gerald Index: porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/porting_to.html,v retrieving revision 1.5 diff -u -r1.5 porting_to.html --- porting_to.html 11 Jun 2014 18:49:26 - 1.5 +++ porting_to.html 12 Apr 2015 00:14:41 - @@ -13,7 +13,7 @@ a href=https://gcc.gnu.org/gcc-4.8/changes.html;changes/a. Some of these are a result of bug fixing, and some old behaviors have been intentionally changed in order to support new standards, or relaxed -in standards-conforming ways to facilitate compilation or runtime +in standards-conforming ways to facilitate compilation or run-time performance. Some of these changes are not visible to the naked eye and will not cause problems when updating from older versions. /p @@ -31,9 +31,8 @@ pImprovements to the GCC infrastructure allow improvements in the ability of several existing warnings to spot problematic code. As -such, new warnings may exist for previously warning-free code that -uses -code-Wmaybe-uninitialized/code. +such, new warnings may exist for previously warning-free code when +using code-Wmaybe-uninitialized/code. /p p Although these warnings will @@ -49,8 +48,8 @@ h3More aggressive loop optimizations/h3 pImprovements to the GCC infrastructure allow improvements in -the ability of the optimizers to transform loops. Some loops that previously -invoked undefined behavior may now be turned into endless loops. +the ability of the optimizers to transform loops. Some loops that +invoke undefined behavior may now be turned into endless loops. /p pFor example,/p @@ -68,7 +67,8 @@ /pre p -When fd is 64 or above, fd * 0x0201 overflows, which is invalid in C/C++ for signed ints. +When fd is 64 or above, fd * 0x0201 overflows, which is invalid for +signed ints in C/C++. /p p @@ -119,13 +119,13 @@ ^ /pre -pAlthough these warnings will not result in compilation failure, -often code-Wall/code is used in conjunction with +pAlthough these warnings will not result in compilation failure per +se, often code-Wall/code is used in conjunction with code-Werror/code and as a result, new warnings are turned into new errors./p -pTo fix, either re-write to use memcpy or dereference the last argument in the -offending memset call./p +pTo fix, either re-write to use codememcpy/code or dereference the +last argument in the offending codememset/code call./p pAs a workaround, use code-Wno-sizeof-pointer-memaccess/code. @@ -134,7 +134,7 @@ h3Pre-processor pre-includes/h3 p -The GCC pre-processor may now pre-includes a file that defines certain +The GCC pre-processor may now pre-include a file that defines certain macros for the entirety of the translation unit. This allows fully conformant implementations of C99/C11 and other standards that require compiler or compiler + runtime macros that describe @@ -142,7 +142,7 @@ /p p -On linux, lt;stdc-predef.hgt; is pre-included. +On GNU/Linux, lt;stdc-predef.hgt; is pre-included. /p p @@ -154,8 +154,9 @@ /usr/include/stdc-predef.h:0: error: Syntax error near '3' /pre -pAs a workaround, the stdc-predef.h preinclude can be disabled with -the use of code-ffreestanding/code. For non C/C++ code, use the pre-processor flag code-P/code. +pAs a workaround, the stdc-predef.h pre-include can be disabled with +the use of code-ffreestanding/code. For non C/C++ code, use the +pre-processor flag code-P/code. /p h2C++ language issues/h2
[doc] Add Maxim Kuvyrkov to contrib.texi
Earlier this year I realized Maxim was completely missing, so here we go. Applied. 2015-04-12 Gerald Pfeifer ger...@pfeifer.com * doc/contrib.texi (Contributors): Add Maxim Kuvyrkov. Index: doc/contrib.texi === --- doc/contrib.texi(revision 222018) +++ doc/contrib.texi(working copy) @@ -509,6 +509,10 @@ Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 effort. @item +Maxim Kuvyrkov for contributions to the instruction scheduler, the Android +and m68k/Coldfire ports, and optimizations. + +@item Charles LaBrec contributed the support for the Integrated Solutions 68020 system.
[PATCH] PR debug/61352 back port from mainline
The attached patch is a back port of the change from https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=211067 for gcc-4_9-branch. Bootstrap and regression tested on x86_64-apple-darwin14 with Xcode 6.3. Okay for gcc-4_9-branch? Jack 2015-04-12 Jack Howarth howarth.at@gmail.com Backport from mainline 2014-05-29 Mike Stump mikest...@comcast.net PR debug/61352 * collect2.c (maybe_run_lto_and_relink): Be sure to always run post ld passes when lto is used. Index: gcc/collect2.c === --- gcc/collect2.c (revision 222021) +++ gcc/collect2.c (working copy) @@ -848,6 +848,8 @@ maybe_run_lto_and_relink (char **lto_ld_ fork_execute (ld, lto_ld_argv); post_ld_pass (false); } + else +post_ld_pass (true); } /* Main program. */
New Swedish PO file for 'gcc' (version 5.1-b20150208)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-5.1-b20150208.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
New Finnish PO file for 'gcc' (version 5.1-b20150208)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Finnish team of translators. The file is available at: http://translationproject.org/latest/gcc/fi.po (This file, 'gcc-5.1-b20150208.fi.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [PATCH 1/4] Docs: extend.texi: Add missing semicolon for consistency
On Sun, 12 Apr 2015, Michael Witten wrote: Well, now! What a pleasant surprise! I was looking for a reason to crack open a beer, and this shall do nicely. :-) Say, how did you end up coming across this patch after nearly 4 years? I keep things that might require attention in case nobody else bites or that look they'll take longer I have at the moment for later. Unfortunately things did accumulate a bit the last years, but it's clearing up. If you have any further patches, let us know, and I'll strive to be faster by an order of magnitude or two. Gerald
Re: [C++ PATCH] Fix up cxx_eval_pointer_plus_expression (PR c++/65736)
OK. Jason
[PATCH] Fix ICF ICE (PR tree-optimization/65747)
Hi!
On the following testcase, ICF assumes OBJ_TYPE_REF_OBJECT must be a
SSA_NAME, but that is not the case in the testcase, where it is
ADDR_EXPR of MEM_REF instead.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2015-04-12 Jakub Jelinek ja...@redhat.com
PR tree-optimization/65747
* ipa-icf-gimple.c (func_checker::compare_operand): Use compare_operand
rather than compare_ssa_name for OBJ_TYPE_REF_OBJECT.
* g++.dg/torture/pr65747.C: New test.
--- gcc/ipa-icf-gimple.c.jj 2015-03-14 09:49:39.0 +0100
+++ gcc/ipa-icf-gimple.c2015-04-12 17:12:37.093411034 +0200
@@ -521,8 +521,8 @@ func_checker::compare_operand (tree t1,
if (!types_same_for_odr (obj_type_ref_class (t1),
obj_type_ref_class (t2)))
return return_false_with_msg (OBJ_TYPE_REF OTR type mismatch);
- if (!compare_ssa_name (OBJ_TYPE_REF_OBJECT (t1),
- OBJ_TYPE_REF_OBJECT (t2)))
+ if (!compare_operand (OBJ_TYPE_REF_OBJECT (t1),
+ OBJ_TYPE_REF_OBJECT (t2)))
return return_false_with_msg (OBJ_TYPE_REF object mismatch);
}
--- gcc/testsuite/g++.dg/torture/pr65747.C.jj 2015-04-12 17:09:15.302632192
+0200
+++ gcc/testsuite/g++.dg/torture/pr65747.C 2015-04-12 17:11:39.003338317
+0200
@@ -0,0 +1,48 @@
+// PR tree-optimization/65747
+// { dg-do compile }
+
+struct A {};
+struct E {
+ virtual A m2();
+} *a;
+struct B {
+ char b[sizeof (E)];
+ void m1();
+};
+struct C {
+ B c;
+ void m3() { c.m1(); }
+ friend class D;
+};
+struct D {
+ int m4(C);
+ void m5();
+ void m6(int, C);
+ void m7(int, C);
+ void m8();
+ bool m9();
+ void m10(int);
+ void m11(int);
+};
+void B::m1() { a = (E *)b; a-m2(); }
+void D::m10(int) { m8(); }
+void D::m11(int) { m8(); }
+int D::m4(C p1) { p1.m3(); return 0; }
+void D::m6(int, C p2) {
+ int b = 0;
+ if (m9()) {
+m4(p2);
+m10(b);
+ } else
+m5();
+ m10(int());
+}
+void D::m7(int, C p2) {
+ int c = 0;
+ if (m9()) {
+m4(p2);
+m11(c);
+ } else
+m5();
+ m11(int());
+}
Jakub
[PATCH] Change gcc_release for 5+
Hi!
Here is an attempt to adjust gcc_release for 5+ versioning scheme.
The second hunk hopefully will use the right branch version, the first hunk
(to be tested when -f will be invoked) should bump automatically BASE-VER
(e.g. from 5.0.1 to 5.1.0).
I'd think we should perhaps also change all the ${SVN} -q ci invocations, so
that we do all the changes together and commit as one larger commit.
2015-04-12 Jakub Jelinek ja...@redhat.com
* gcc_release: For RELEASE_MAJOR 5+ only use the major
number in branch name. When doing final release of 5+,
if BASE-VER doesn't match release, but is *.*.1 for the
one smaller minor version, bump BASE-VER.
--- gcc_release (revision 221957)
+++ gcc_release (working copy)
@@ -9,7 +9,7 @@
# Contents:
# Script to create a GCC release.
#
-# Copyright (c) 2001-2014 Free Software Foundation.
+# Copyright (c) 2001-2015 Free Software Foundation.
#
# This file is part of GCC.
#
@@ -130,8 +130,20 @@ EOF
# Update gcc/DEV-PHASE.
-[ `cat ${SOURCE_DIRECTORY}/gcc/BASE-VER` = ${RELEASE} ] || \
-error Release number ${RELEASE} does not match BASE-VER
+if [ `cat ${SOURCE_DIRECTORY}/gcc/BASE-VER` = ${RELEASE} ]; then
+ [ ${RELEASE_MAJOR} -lt 5 ] \
+ error Release number ${RELEASE} does not match BASE-VER
+ if [ `cat ${SOURCE_DIRECTORY}/gcc/BASE-VER` \
+ = ${RELEASE_MAJOR}.`expr ${RELEASE_MINOR} - 1`.1 \
+ -a x${RELEASE_REVISION} = x0 ]; then
+ (changedir ${SOURCE_DIRECTORY}/gcc \
+echo ${RELEASE} BASE-VER \
+${SVN} -q ci -m 'Bump release' BASE-VER) || \
+ error Could not update BASE-VER
+ else
+ error Release number ${RELEASE} does not match BASE-VER
+ fi
+fi
(changedir ${SOURCE_DIRECTORY}/gcc \
: DEV-PHASE \
${SVN} -q ci -m 'Mark as release' DEV-PHASE) || \
@@ -605,7 +617,11 @@ if [ $SNAPSHOT -eq 0 ]; then
# Compute the name of the branch, which is based solely on the major
# and minor release numbers.
- SVNBRANCH=branches/gcc-${RELEASE_MAJOR}_${RELEASE_MINOR}-branch
+ if [ ${RELEASE_MAJOR} -ge 5 ]; then
+SVNBRANCH=branches/gcc-${RELEASE_MAJOR}-branch
+ else
+SVNBRANCH=branches/gcc-${RELEASE_MAJOR}_${RELEASE_MINOR}-branch
+ fi
# If this is not a final release, set various parameters accordingly.
if [ ${FINAL} -ne 1 ]; then
Jakub
Re: [PATCH] -Wmemset-transposed-args (PR middle-end/61294, take 2)
Hi Jakub,
On Fri, 11 Jul 2014, Jakub Jelinek wrote:
So like this? Also have fixed one omitted line in c-parser.c,
this patch bootstrapped/regtested fine:
just in time for GCC 5.1 RC1 :-) a small update on top of yours.
Committed.
Gerald
2015-04-12 Gerald Pfeifer ger...@pfeifer.com
* doc/invoke.texi (-Wmemset-transposed-args): Break a long
sentence. Improve grammar.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 222021)
+++ doc/invoke.texi (working copy)
@@ -4909,10 +4909,10 @@
second argument is not zero and the third argument is zero. This warns e.g.@
about @code{memset (buf, sizeof buf, 0)} where most probably
@code{memset (buf, 0, sizeof buf)} was meant instead. The diagnostics
-is only emitted if the third argument is literal zero, if it is some expression
-that is folded to zero, or e.g. a cast of zero to some type etc., it
-is far less likely that user has mistakenly exchanged the arguments and
-no warning is emitted. This warning is enabled by @option{-Wall}.
+is only emitted if the third argument is literal zero. If it is some
+expression that is folded to zero, a cast of zero to some type, etc.,
+it is far less likely that the user has mistakenly exchanged the arguments
+and no warning is emitted. This warning is enabled by @option{-Wall}.
@item -Waddress
@opindex Waddress
Re: [PATCH] Fix ICF ICE (PR tree-optimization/65747)
On April 12, 2015 9:08:34 PM GMT+02:00, Jakub Jelinek ja...@redhat.com wrote:
Hi!
On the following testcase, ICF assumes OBJ_TYPE_REF_OBJECT must be a
SSA_NAME, but that is not the case in the testcase, where it is
ADDR_EXPR of MEM_REF instead.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for
trunk?
OK.
Thanks,
Richard.
2015-04-12 Jakub Jelinek ja...@redhat.com
PR tree-optimization/65747
* ipa-icf-gimple.c (func_checker::compare_operand): Use
compare_operand
rather than compare_ssa_name for OBJ_TYPE_REF_OBJECT.
* g++.dg/torture/pr65747.C: New test.
--- gcc/ipa-icf-gimple.c.jj2015-03-14 09:49:39.0 +0100
+++ gcc/ipa-icf-gimple.c 2015-04-12 17:12:37.093411034 +0200
@@ -521,8 +521,8 @@ func_checker::compare_operand (tree t1,
if (!types_same_for_odr (obj_type_ref_class (t1),
obj_type_ref_class (t2)))
return return_false_with_msg (OBJ_TYPE_REF OTR type mismatch);
- if (!compare_ssa_name (OBJ_TYPE_REF_OBJECT (t1),
- OBJ_TYPE_REF_OBJECT (t2)))
+ if (!compare_operand (OBJ_TYPE_REF_OBJECT (t1),
+OBJ_TYPE_REF_OBJECT (t2)))
return return_false_with_msg (OBJ_TYPE_REF object mismatch);
}
--- gcc/testsuite/g++.dg/torture/pr65747.C.jj 2015-04-12
17:09:15.302632192 +0200
+++ gcc/testsuite/g++.dg/torture/pr65747.C 2015-04-12
17:11:39.003338317 +0200
@@ -0,0 +1,48 @@
+// PR tree-optimization/65747
+// { dg-do compile }
+
+struct A {};
+struct E {
+ virtual A m2();
+} *a;
+struct B {
+ char b[sizeof (E)];
+ void m1();
+};
+struct C {
+ B c;
+ void m3() { c.m1(); }
+ friend class D;
+};
+struct D {
+ int m4(C);
+ void m5();
+ void m6(int, C);
+ void m7(int, C);
+ void m8();
+ bool m9();
+ void m10(int);
+ void m11(int);
+};
+void B::m1() { a = (E *)b; a-m2(); }
+void D::m10(int) { m8(); }
+void D::m11(int) { m8(); }
+int D::m4(C p1) { p1.m3(); return 0; }
+void D::m6(int, C p2) {
+ int b = 0;
+ if (m9()) {
+m4(p2);
+m10(b);
+ } else
+m5();
+ m10(int());
+}
+void D::m7(int, C p2) {
+ int c = 0;
+ if (m9()) {
+m4(p2);
+m11(c);
+ } else
+m5();
+ m11(int());
+}
Jakub
[wwwdocs, patch, committed] gcc-5/changes.html - minor Fortran update
Small Fortran update for https://gcc.gnu.org/gcc-5/changes.html : The main issue with coarray locking has been solved :-) Hence, I committed the patch as obvious. Tobias PS: Gerald: Regarding the approval for gcc-5/changes.html: Mention that C FE can be build as libcc1.so: I withdraw/drew the patch based on Jakub's comments. Thus, I leave the annoucement to https://sourceware.org/gdb/download/ANNOUNCEMENT Index: htdocs/gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.103 diff -u -p -r1.103 changes.html --- htdocs/gcc-5/changes.html 12 Apr 2015 01:03:08 - 1.103 +++ htdocs/gcc-5/changes.html 12 Apr 2015 20:26:12 - @@ -536,7 +536,7 @@ void operator delete[] (void *, std::siz ul lia href=https://gcc.gnu.org/wiki/Coarray;Coarrays/a: Full experimental support of Fortran 2008's coarrays with - code-fcoarray=lib/code except for locking and allocatable/pointer + code-fcoarray=lib/code except for allocatable/pointer components of derived-type coarrays. GCC currently only ships with a single-image library (codelibcaf_single/code), but multi-image support based on MPI and GASNet is provided by the libraries
[doc] Add Martin Jambor and Michael Matz to contrib.texi
...a Honza/Gerald co-production. :-) Applied.
Jakub, is this (and another one I should have in the next few
days) okay to backport even after RC1?
Gerald
2015-04-12 Jan Hubicka hubi...@ucw.cz
Gerald Pfeifer ger...@pfeifer.com
* doc/contrib.texi (Contributors): Add Martin Jambor and
Michael Matz.
Index: doc/contrib.texi
===
--- doc/contrib.texi(revision 222022)
+++ doc/contrib.texi(working copy)
@@ -434,6 +434,10 @@
Andreas Jaeger for testing and benchmarking of GCC and various bug fixes.
@item
+Martin Jambor for his work on inter-procedural optimizations, the
+switch conversion pass, and scalar replacement of aggregates.
+
+@item
Jakub Jelinek for his SPARC work and sibling call optimizations as well
as lots of bug fixes and test cases, and for improving the Java build
system.
@@ -605,6 +609,10 @@
improvements, and string clean up and testsuites.
@item
+Michael Matz for his work on dominance tree discovery, the x86-64 port,
+link-time optimization framework and general optimization improvements.
+
+@item
All of the Mauve project
@uref{http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/mauve/THANKS?rev=1.2cvsroot=mauveonly_with_tag=HEAD,,contributors},
for Java test code.
[patch, libgfortran] PR65089 FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address
Hi all,
The attached patch fixes this bug. It also eliminates non-freed memory whenever
a format error occurs. Particular important when the user has use IOSTAT and
generate_error does not exit, but returns to continue program execution.
Regression tested on x86-64 and tested with -fsanitize=address and valgrind on a
number of existing test cases. Changelog is fairly clear I think.
OK for trunk?
Regards,
Jerry
2015-04-12 Jerry DeLisle jvdeli...@gcc.gnu.org
PR libgfortran/65089
* io/format.h (free_format): New function to free memory
allocated for building format error messages.
* io/format.c (format_error): Add checks before freeing memory
to avoid potential segfaults and free formatting data when
needed on error conditions. Always allocate and NULL terminate
the string.
* io/transfer.c (st_read_done, st_write_done): Use new
free_format function to clean up memory allocations when done.
Index: io/format.c
===
--- io/format.c (revision 222011)
+++ io/format.c (working copy)
@@ -243,6 +243,18 @@ get_fnode (format_data *fmt, fnode **head, fnode *
}
+/* free_format()-- Free allocated format string. */
+void
+free_format (st_parameter_dt *dtp)
+{
+ if ((dtp-common.flags IOPARM_DT_HAS_FORMAT dtp-format))
+{
+ free (dtp-format);
+ dtp-format = NULL;
+}
+}
+
+
/* free_format_data()-- Free all allocated format data. */
void
@@ -1145,7 +1157,8 @@ format_error (st_parameter_dt *dtp, const fnode *f
p = strchr (buffer, '\0');
- memcpy (p, dtp-format, width);
+ if (dtp-format)
+memcpy (p, dtp-format, width);
p += width;
*p++ = '\n';
@@ -1158,6 +1171,26 @@ format_error (st_parameter_dt *dtp, const fnode *f
*p++ = '^';
*p = '\0';
+ /* Cleanup any left over memory allocations before calling generate
+ error. */
+ if (is_internal_unit (dtp))
+{
+ if (dtp-format != NULL)
+ {
+ free (dtp-format);
+ dtp-format = NULL;
+ }
+
+ /* Leave these alone if IOSTAT was given because execution will
+ return from generate error in those cases. */
+ if (!(dtp-common.flags IOPARM_HAS_IOSTAT))
+ {
+ free (dtp-u.p.fmt);
+ free_format_hash_table (dtp-u.p.current_unit);
+ free_internal_unit (dtp);
+ }
+}
+
generate_error (dtp-common, LIBERROR_FORMAT, buffer);
}
@@ -1218,13 +1251,10 @@ parse_format (st_parameter_dt *dtp)
/* Not found so proceed as follows. */
- if (format_cache_ok)
-{
- char *fmt_string = xmalloc (dtp-format_len + 1);
- memcpy (fmt_string, dtp-format, dtp-format_len);
- dtp-format = fmt_string;
- dtp-format[dtp-format_len] = '\0';
-}
+ char *fmt_string = xmalloc (dtp-format_len + 1);
+ memcpy (fmt_string, dtp-format, dtp-format_len);
+ dtp-format = fmt_string;
+ dtp-format[dtp-format_len] = '\0';
dtp-u.p.fmt = fmt = xmalloc (sizeof (format_data));
fmt-format_string = dtp-format;
@@ -1256,19 +1286,13 @@ parse_format (st_parameter_dt *dtp)
else
fmt-error = Missing initial left parenthesis in format;
- if (fmt-error)
-{
- format_error (dtp, NULL, fmt-error);
- if (format_cache_ok)
- free (dtp-format);
- free_format_hash_table (dtp-u.p.current_unit);
- return;
-}
-
if (format_cache_ok)
save_parsed_format (dtp);
else
dtp-u.p.format_not_saved = 1;
+
+ if (fmt-error)
+format_error (dtp, NULL, fmt-error);
}
Index: io/format.h
===
--- io/format.h (revision 222011)
+++ io/format.h (working copy)
@@ -132,6 +132,9 @@ internal_proto(format_error);
extern void free_format_data (struct format_data *);
internal_proto(free_format_data);
+extern void free_format (st_parameter_dt *);
+internal_proto(free_format);
+
extern void free_format_hash_table (gfc_unit *);
internal_proto(free_format_hash_table);
Index: io/transfer.c
===
--- io/transfer.c (revision 222011)
+++ io/transfer.c (working copy)
@@ -3711,9 +3711,15 @@ void
st_read_done (st_parameter_dt *dtp)
{
finalize_transfer (dtp);
+
if (is_internal_unit (dtp) || dtp-u.p.format_not_saved)
-free_format_data (dtp-u.p.fmt);
+{
+ free_format_data (dtp-u.p.fmt);
+ free_format (dtp);
+}
+
free_ionml (dtp);
+
if (dtp-u.p.current_unit != NULL)
unlock_unit (dtp-u.p.current_unit);
@@ -3764,8 +3770,13 @@ st_write_done (st_parameter_dt *dtp)
}
if (is_internal_unit (dtp) || dtp-u.p.format_not_saved)
-free_format_data (dtp-u.p.fmt);
+{
+ free_format_data (dtp-u.p.fmt);
+ free_format (dtp);
+}
+
free_ionml (dtp);
+
if (dtp-u.p.current_unit != NULL)
unlock_unit (dtp-u.p.current_unit);
