Re: LIBGCC2_FLAGS not used by libgcc2 configure?
On 18/06/11 00:00, Ian Lance Taylor wrote: You are saying that configure is using TARGET_LIBGCC2_FLAGS, but that you want to set something so that it uses TARGET_LIBGCC2_FLAGS? Are you missing a "not" in there somewhere? Or do I misunderstand? Thanks for the reply Ian. I am using MULTILIBS. However, there's a flag that I want all the LIBGCC2 built with. That's a special flag for my backend -mas-mode. I added this to TARGET_LIBGCC2_FLAGS, however, libgcc/configure is not passing this flag to the configure programs and configure simply flags. I noticed that it works if I do make CFLAGS_FOR_BUILD=-mas-mode but I wonder if there's a cleaner way (so that I don't need to pass flags through the command line. Is it libgcc/configure that is failing? If so it sounds like you want to set MULTILIB_EXTRA_OPTS, per your earlier question. Yes, it's libgcc/configure that's failing. So, you mean I should MULTILIB_EXTRA_OPTS=-mas-mode in my t- makefile fragment? -- PMatos
Re: Original commit history for gfortran
On 06/19/2011 06:04 PM, "C. Bergström" wrote: 3) Fortran HPC community as a whole - The majority of Fortran users I know work in or around HPC. (I may be biased) With that I can't say most of them care about open source at all. (Some do) They buy/use PathScale/PGI/Intel and for the larger labs I'm not sure if they use gfortran. I think you are biased that most Fortran users work around HPC. They mostly do work in natural science; thus, the kind of programs which run on HPC machines. But there are many users which have programs fast enough to run them on a laptop or work station in serial mode. However, a large minority of those programs also runs in parallel and thus on multi-cores, small clusters up to the HPC machines. While for HPC sites and larger institutions the compiler costs are negligible, for a smaller university group or for the laptop/computer at home, it matters - and gfortran fills the gap. That's also what I hear from vendors: The availability of gfortran - other free Fortran compilers do not seem to play a role (any more) - improves their sales. For HPC sites themselves: All sites I know run Linux have have besides one - or several - vendor compilers also GCC/gfortran installed - and support it. Also some HPC vendors give support to their customers for GCC/gfortran. The reason for having a backup compiler is on one hand that code might not work with the vendor compiler (esp. in case of C/C++) but also if the vendor compiler has a bug. (Someone told me that gfortran saved a PhD thesis by being a replacement for a vendor compiler - with being only minutely slower. The vendor compiler was fixed eventually, but it took several months.) My impression from both HPC sites, from users and other vendors is: All HPC sites have GCC/gfortran installed and use it as additional compiler besides the vendor/commercial compiler(s). Additionally, it is very common to have a commercial compiler at work - and use gfortran at home/on the laptop. Thus, many institutions require that their code also runs with gfortran - even though their main work horse is a commercial compiler. [Personal observation: On x86-64, gfortran is everywhere installed, the Intel compiler is very often, on two systems I also saw PGI - but I have never seen PathScale.] I also do not agree about the statement that they do not care about Open Source. I know several places (large institutions like weather services or small projects) where the availability of a free (mostly: Open Source) compiler is a requirement and features not supported by gfortran my not be included. Thus, gfortran seems to be rather known among users and in the lower management. I heard also of some aviation company which considered to use gfortran because it was the only compiler supporting all their platforms. On the other hand, there are places where only some commercial compiler will do because the management does not trust free/OpenSource software. (They still often have GCC installed additionally.) Most of them want their code to compile, get best performance and sometimes use F2K3. You're not going to stop them from buying commercially supported compilers. First, one can also buy support for GCC and thus gfortran: Either directly via support contracts or indirectly via buying an enterprise Linux distribution. But having a commercial compiler does not rule out having an Open Source compiler; similarly, producing a commercial compiler does not stop companies of also supporting GCC - be it by bug reports, support to customers or directly contribution to the development of GCC. I also use all kinds of compiler: Having multiple compilers helps to find bugs in the code; independent of performance, it is convenient to use the default compiler on a given system - which might be gfortran at home and some commercial compiler at work/HPC centers. However, I do not buy the F2003 and performance argument. gfortran is not really lagging behind Fortran 2003/2008. The number of compilers which are further is quite low and they are also not years ahead. (Though, having a more complete implementation is wished by everyone: Users, compiler developers and also other vendors [at least if they support that feature already].) And with regards to performance, I think GCC is seriously underrated. One reason might be that the default settings are rather on the safe than on the performance side. If I look at benchmarks - such as at the one at Polyhedron (http://www.polyhedron.com/compare0html) I do not see a drastic difference (~25% slower than the fastest compiler for the geometric means) - and the site compares an old version of gfortran against the latest commercial compilers. In my test, GCC 4.7 -Ofast -march=native -funroll-loops -finline-limit=600 is on average 3 to 16% *faster* than the other known-to-be-fast compilers I tested. [1] The variance is large and can easily reach a factor 2 for single
Re: Middle end warnings cascading after C++ parsing errors
On Fri, Jun 17, 2011 at 5:39 PM, Jason Merrill wrote: > On 06/17/2011 10:55 AM, Diego Novillo wrote: >> >> On Fri, Jun 17, 2011 at 14:47, Diego Novillo wrote: >> >>> if (flag_syntax_only || flag_wpa) >>> return; >>> >>> to >>> >>> if (flag_syntax_only || flag_wpa || errorcount> 0) >>> return; >> >> To clarify. It would be 'seen_error ()' instead of 'errorcount> 0', >> but the idea is the same. > > That seems reasonable to me. Yes. I think Steven proposed this as well at some point. Richard. > Jason >
Re: How effect the OpenSource EKOPath the GCC ?
2011/6/18 theUser BL : > > Hi! > > Currently I have nothing about it found in the mailinglist. So I try to ask > it: How effect the OpenSource EKOPath the GCC ? > > Have a look at the latest press news of PathScale: > http://www.pathscale.com/taxonomy/term/27 > > Have additional a look at this articls of phronix: > http://www.phoronix.com/scan.php?page=article&item=pathscale_ekopath4_open&num=1 > http://www.phoronix.com/scan.php?page=news_item&px=OTU2OA Phoronix always picks two single (and stupid) benchmarks. Those have been analyzed already and we know why GCC is not performing well (but two trivial benchmark source modifications will make it perform). Don't be fooled by benchmark numbers. Always benchmark the application you are interested in (and verify its output). Richard.
Re: Backport new -mflat support for SPARC to 4.6 branch
2011/6/20 Eric Botcazou : > Dear RMs, > > I'd like to have permission to backport the new -mflat support for SPARC from > the mainline to the 4.6 branch. I received the first requests to reinstate > the option last year, when Laurent (and some others) started to work on it, > but the initial patch was submitted too late in the 4.6 development cycle, due > to technical and administrative issues. I nevertheless think that it would be > too bad to postpone its availabilty by another full year. > > The bulk of the changes are to the SPARC back-end, but there are a few minor > adjustments to the generic RTL code, namely 3 one-liners to builtins.c, cse.c > and postreload-gcse.c. I think that the risk for non-SPARC targets is nearly > null (and is acceptable for the SPARC port at this point in the 4.6 cycle). > > The patch has already been written and tested on the branch (on x86/Linux, > SPARC/Solaris and SPARC64/Solaris) so it could be applied immediately. The > patches from mainline it is made up of are listed at the end of the message. > > Can I proceed with the backport? Apart from 2011-06-02 Eric Botcazou * cse.c (cse_find_path): Refine change to exclude EDGE_ABNORMAL_CALL edges only, when there is a non-local label in the function. * postreload-gcse.c (bb_has_well_behaved_predecessors): Likewise. and the removal of SETJMP_VIA_SAVE_AREA this affects sparc only, right? Do you expect out-of-tree ports based on 4.6 may use this feature? Is there any harm in not backporting these two changes? Otherwise you are a sparc maintainer, its a primary platform, and I expect you're not going to break it. Thus, for a target specific feature backport to a .1 release I think it's ok. But please coordinate with Jakub who wants to do a RC1 soon. Richard. > > 2011-06-10 Eric Botcazou > Laurent Rougé > > * doc/invoke.texi (SPARC options): Add -mflat. > * config/sparc/sparc.opt: Likewise. > * config/sparc/sparc-protos.h (sparc_expand_epilogue): Add parameter. > (sparc_flat_expand_prologue): Declare. > (sparc_flat_expand_epilogue): Likewise. > * config/sparc/sparc.h (CPP_CPU_SPEC): Do not handle -msoft-float. > (CPP_ENDIAN_SPEC): Replace with... > (CPP_OTHER_SPEC): ...this. Also handle -mflat and -msoft-float. > (CPP_SPEC): Adjust to above change. > (EXTRA_SPECS): Likewise. > (SPARC_INCOMING_INT_ARG_FIRST): Add TARGET_FLAT handling. > (INCOMING_REGNO): Likewise. > (OUTGOING_REGNO): Likewise. > (LOCAL_REGNO): Likewise. > (SETUP_FRAME_ADDRESSES): Likewise. > (FIXED_REGISTERS): Set 0 for %fp. > (CALL_USED_REGISTERS): Likewise. > (INITIAL_ELIMINATION_OFFSET): Pass current_function_is_leaf. > (EXIT_IGNORE_STACK): Define to 1 unconditionally. > (RETURN_ADDR_REGNUM): Define. > (RETURN_ADDR_RTX): Use it. > (INCOMING_RETURN_ADDR_REGNUM): Define. > (INCOMING_RETURN_ADDR_RTX): Use it. > (DWARF_FRAME_RETURN_COLUMN): Likewise. > (EH_RETURN_REGNUM): Define. > (EH_RETURN_STACKADJ_RTX): Use it. > (EH_RETURN_HANDLER_RTX): Delete. > (EPILOGUE_USES): Use them and add TARGET_FLAT handling. > * config/sparc/sparc.c (apparent_fsize, actual_fsize, num_gfregs): > Delete. > (struct machine_function): Add frame_size, apparent_frame_size, > frame_base_reg, frame_base_offset, n_global_fp_regs and > save_local_in_regs_p fields. > (sparc_frame_size, sparc_apparent_frame_size, sparc_frame_base_reg, > sparc_frame_base_offset, sparc_n_global_fp_regs, > sparc_save_local_in_regs_p): New macros. > (sparc_option_override): Error out if -fcall-saved-REG is specified > for Out registers. > (eligible_for_restore_insn): Fix formatting. > (eligible_for_return_delay): Likewise. Add TARGET_FLAT handling. > (eligible_for_sibcall_delay): Likewise. > (RTX_OK_FOR_OFFSET_P, RTX_OK_FOR_OLO10_P): Add MODE parameter. > (sparc_legitimate_address_p): Adjust to above change. > (save_global_or_fp_reg_p): New predicate. > (return_addr_reg_needed_p): Likewise. > (save_local_or_in_reg_p): Likewise. > (sparc_compute_frame_size): Use them. Add TARGET_FLAT handling. > (SORR_SAVE, SORR_RESTORE): Delete. > (sorr_pred_t): New typedef. > (sorr_act_t): New enum. > (save_or_restore_regs): Rename to... > (emit_save_or_restore_regs): ...this. Change type of LOW and HIGH > parameters, remove ACTION parameter, add LEAF_FUNCTION_P, SAVE_P, > ACTION_TRUE and ACTION_FALSE parameters. Implement more general > mechanism. Add CFI information for double-word saves in 32-bit mode. > (emit_adjust_base_to_offset): New function extracted from... > (emit_save_or_restore_regs): ...this. Rename the rest to... > (emit_save_or_restore_regs_global_fp_regs):
Re: Backport new -mflat support for SPARC to 4.6 branch
On Mon, Jun 20, 2011 at 01:21:39PM +0200, Richard Guenther wrote: > Otherwise you are a sparc maintainer, its a primary > platform, and I expect you're not going to break it. Thus, for a > target specific feature backport to a .1 release I think it's ok. But > please coordinate with Jakub who wants to do a RC1 soon. RC1 is already building though, could it wait for 4.6.2? If it is committed soon after 4.6.1 is released, it will get more testing before it is actually released, and 4.6.2 shouldn't bee too far (around 3 months or so). Jakub
Re: Backport new -mflat support for SPARC to 4.6 branch
> Apart from > > 2011-06-02 Eric Botcazou > >* cse.c (cse_find_path): Refine change to exclude EDGE_ABNORMAL_CALL >edges only, when there is a non-local label in the function. >* postreload-gcse.c (bb_has_well_behaved_predecessors): Likewise. > > and the removal of SETJMP_VIA_SAVE_AREA this affects sparc only, right? Yes, only 3 one-liner changes can affect non-SPARC platforms, and only if you use fancy features (non-local gotos or __builtin_setjmp/__builtin_longjmp). > Do you expect out-of-tree ports based on 4.6 may use this feature? Probably, maybe 4.5-based tree as well, but no firm answer. > Is there any harm in not backporting these two changes? Yes, small regressions to the above fancy features for the SPARC port. -- Eric Botcazou
Re: Backport new -mflat support for SPARC to 4.6 branch
On Mon, Jun 20, 2011 at 1:46 PM, Eric Botcazou wrote: >> Apart from >> >> 2011-06-02 Eric Botcazou >> >> * cse.c (cse_find_path): Refine change to exclude EDGE_ABNORMAL_CALL >> edges only, when there is a non-local label in the function. >> * postreload-gcse.c (bb_has_well_behaved_predecessors): Likewise. >> >> and the removal of SETJMP_VIA_SAVE_AREA this affects sparc only, right? > > Yes, only 3 one-liner changes can affect non-SPARC platforms, and only if you > use fancy features (non-local gotos or __builtin_setjmp/__builtin_longjmp). > >> Do you expect out-of-tree ports based on 4.6 may use this feature? > > Probably, maybe 4.5-based tree as well, but no firm answer. So I'd say leave support for it in on the branch. >> Is there any harm in not backporting these two changes? > > Yes, small regressions to the above fancy features for the SPARC port. As it'll be postponed for 4.6.2 I guess it will receive enough testing, so ok. Richard. > -- > Eric Botcazou >
Re: LIBGCC2_FLAGS not used by libgcc2 configure?
"Paulo J. Matos" writes: >> Is it libgcc/configure that is failing? If so it sounds like you want >> to set MULTILIB_EXTRA_OPTS, per your earlier question. >> > > Yes, it's libgcc/configure that's failing. So, you mean I should > MULTILIB_EXTRA_OPTS=-mas-mode in my t- makefile fragment? Yes. Alternatively, you implied that your backend always needs this option. In that case you could make it the default or you could add it to DRIVER_SELF_SPECS. Or did you just mean that you always need it for libgcc2 but not for user code? Ian
GCC 4.6.1 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.6.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.1-RC-20110620 and shortly its mirrors. It has been generated from SVN revision 175201. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.6.1 early next week.
GCC 4.6.1 Status Report (2011-06-20) [BRANCH FROZEN]
Status == GCC 4.6.1 first release candidate has been uploaded, and the branch is now frozen. All changes need RM approval now. Please test it, if all goes well, 4.6.1 will be released early next week. Quality Data Priority # Change from Last Report --- --- P10 +- 0 P2 98 + 4 P3 10 - 3 --- --- Total 108 + 1 Previous Report === http://gcc.gnu.org/ml/gcc/2011-04/msg00349.html The next report for 4.6.1 will be sent by me again.
Re: Original commit history for gfortran
On Sun, Jun 19, 2011 at 11:04:09PM +0700, "C. Bergstr?m" wrote: > 3) Fortran HPC community as a whole - The majority of Fortran users I > know work in or around HPC. (I may be biased) With that I can't say > most of them care about open source at all. (Some do) They buy/use > PathScale/PGI/Intel and for the larger labs I'm not sure if they use > gfortran. (They may, but I really don't have that data) Most of them > want their code to compile, get best performance and sometimes use > F2K3. You're not going to stop them from buying commercially supported > compilers. I think biggest fortran users are organisations which are very conservative by design - power generation (particularly nuclear) and defence. For example, I've head from a colleague in Geography, who handled Met Office's (UK national weather predition service) fortran code that some routines in their production code are still in Fortran IV. These organisations are probably better characterised as mission critical, than HPC. All your VMS, NonStop, etc. I'd say F2K3 is pretty low on the agenda for them. I think it's those businesses that make the most of fortran user community, even though they are very quiet. Given their conservatism, they are not going to switch to anything else any time soon. That is not to say that they don't use other languages, just that they are not dropping fortran as their main production language. They might just be curious about an open source compiler, but probably never as a first choice. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423
Re: Original commit history for gfortran
On Mon, Jun 20, 2011 at 12:44:06PM +0200, Tobias Burnus wrote: > > compiler. [Personal observation: On x86-64, gfortran is everywhere > installed, the Intel compiler is very often, on two systems I also saw > PGI - but I have never seen PathScale.] we use it: https://www.acrc.bris.ac.uk/acrc/phase1_software.htm -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423
Re: LIBGCC2_FLAGS not used by libgcc2 configure?
On 20/06/11 13:08, Ian Lance Taylor wrote:
Yes, it's libgcc/configure that's failing. So, you mean I should
MULTILIB_EXTRA_OPTS=-mas-mode in my t- makefile fragment?
Yes.
I will give that a try.
Alternatively, you implied that your backend always needs this option.
In that case you could make it the default or you could add it to
DRIVER_SELF_SPECS. Or did you just mean that you always need it for
libgcc2 but not for user code?
My backend as two 'compilation modes' (the generated code differs slightly).
I added a define into the command line by doing
make CFLAGS_FOR_BUILD="-DAS_MODE"
and then in my backend header:
#ifdef AS_MODE
#undef CC1_SPEC
#define CC1_SPEC "%{!mas-mode:-mas-mode}"
#endif
However, this is not working since gcc.c is not being compiled with the
CFLAGS_FOR_BUILD, meaning it's not being passed -DAS_MODE in the command
line and therefore no defining CC1_SPEC.
Which flag (like CFLAGS_FOR_BUILD) can I use that is passed in the
command line to compile the driver?
Cheers,
--
Paulo Matos
Re: Middle end warnings cascading after C++ parsing errors
On Mon, Jun 20, 2011 at 10:47, Richard Guenther wrote: > On Fri, Jun 17, 2011 at 5:39 PM, Jason Merrill wrote: >> >> That seems reasonable to me. > > Yes. I think Steven proposed this as well at some point. Alright, thanks. Unsurprisingly, this produces 152 failures in the testsuite. I have not analyzed the reasons yet, but I hope it's just tweaking expect lines in the tests. Diego.
Re: Backport new -mflat support for SPARC to 4.6 branch
> As it'll be postponed for 4.6.2 I guess it will receive enough testing, so > ok. I'm not sure you're really convinced either. :-) IMO putting it on the branch after the 4.6.1 release won't increase the testing much there, since people generally test/use releases or mainline. You get the real testing when you release and I think that the .1 release would have been appropriate. I'm not so sure for the .2 release, as this would mean waiting for 4.6.3 to fix the probable fallouts for the SPARC port. I guess we'd better drop the idea then. -- Eric Botcazou
RE: GCC 4.6.1 Status Report (2011-06-20) [BRANCH FROZEN]
> GCC 4.6.1 first release candidate has been uploaded, and the branch > is now frozen. All changes need RM approval now. > Please test it, if all goes well, 4.6.1 will be released early next > week. No chance for a fix for this in 4.6.1? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 This has been a critical regression for us, forcing the removal of cold attributes which in turn has reduced performance by a notable amount due to decreased spatial locality. If cold attributes are a sufficiently obscure feature that doesn't warrant a P1, let me know and I'll set expectations appropriately. Thanks!
Re: Original commit history for gfortran
On 06/20/2011 03:22 PM, Anton Shterenlikht wrote: On Mon, Jun 20, 2011 at 12:44:06PM +0200, Tobias Burnus wrote: compiler. [Personal observation: On x86-64, gfortran is everywhere installed, the Intel compiler is very often, on two systems I also saw PGI - but I have never seen PathScale.] we use it: https://www.acrc.bris.ac.uk/acrc/phase1_software.htm According to this information (after clicking through a couple of times) you use gcc/g77 3.4.6 (which is understandable if you have code that uses extensions only g77 supports) and gcc/gfortran 4.1.0. 4.1.0 is *quite* old - I suggest upgrading to at least 4.4 or possibly 4.5. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
svn issue when svnmerge merge-ing trunk into MELT
Hello,
I am trying to merge the trunk into MELT branch. I am using the
svnmerge merge command (svnmerge is a standard Python script). But I am
getting: % svn commit
Waiting for Emacs...
Sending.
SendingChangeLog
SendingChangeLog.MELT
Sendingconfig/ChangeLog
Sendingconfig/mh-darwin
Sendingconfigure
Sendingconfigure.ac
Sendinggcc/ChangeLog
Sendinggcc/DATESTAMP
Sendinggcc/Makefile.in
[...]
Adding gcc/common/config/alpha
Adding gcc/common/config/alpha/alpha-common.c
[...]
Sendinglibstdc++-v3/testsuite/30_threads/thread/swap
Sendinglibstdc++-v3/testsuite/ext/profile
Sendinglibstdc++-v3/testsuite/ext/rope/pthread7-rope.cc
Transmitting file
data
..svn:
Commit failed (details follow): svn: File already exists: filesystem
'/svn/gcc/db', transaction '175226-py9', path
'/branches/melt-branch/gcc/common/common-target-def.h' svn: Your commit
message was left in a temporary file: svn:
'/usr/src/Lang/basile-melt-gcc/svn-commit.tmp'
Usually, I manage to handle that by ./contrib/gcc_update-ing and then
reissuing the svnmerge command. But here it failed three times.
svnmerge is from the subversion-tools ; on Debian/Sid I have
+++-==-==-
ii subversion 1.6.17dfsg-1 Advanced version control system
ii subversion-too 1.6.17dfsg-1 Assorted tools related to Subversion
Do you have any advice on dealing with that? Or explanations?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: svn issue when svnmerge merge-ing trunk into MELT
On Mon, 20 Jun 2011 20:14:15 +0200
Basile Starynkevitch wrote:
> [...]
> Sendinglibstdc++-v3/testsuite/30_threads/thread/swap
> Sendinglibstdc++-v3/testsuite/ext/profile
> Sendinglibstdc++-v3/testsuite/ext/rope/pthread7-rope.cc
> Transmitting file
> data
> ..svn:
> Commit failed (details follow): svn: File already exists: filesystem
> '/svn/gcc/db', transaction '175226-py9', path
> '/branches/melt-branch/gcc/common/common-target-def.h' svn: Your commit
> message was left in a temporary file: svn:
> '/usr/src/Lang/basile-melt-gcc/svn-commit.tmp'
>
By checking out from scratch the MELT branch, and running svnmerge
merge again, I was able to do that merge.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
merged trunk svn 175225 into MELT branch
Hello All
I just merged trunk into MELT. So using the newly introduced
c_register_pragma_with_expansion_and_data in MELT can be possible...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: GCC 4.6.1 Status Report (2011-06-20) [BRANCH FROZEN]
On Mon, Jun 20, 2011 at 05:32:31PM +, Hargett, Matt wrote: > > GCC 4.6.1 first release candidate has been uploaded, and the branch > > is now frozen. All changes need RM approval now. > > Please test it, if all goes well, 4.6.1 will be released early next > > week. > > No chance for a fix for this in 4.6.1? Unlikely. Honza seems to be busy with LTO right now. Hopefully it will get fixed in 4.6.2. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 > > This has been a critical regression for us, forcing the removal of cold > attributes which in turn has reduced performance by a notable amount due > to decreased spatial locality. > > If cold attributes are a sufficiently obscure feature that doesn't warrant > a P1, let me know and I'll set expectations appropriately. It is P2, not P1. cold attributes aren't used very often, therefore it is much less tested than more commonly used features. Try to use __builtin_expect instead where appropriate for the time being. Jakub
