Doubt regarding gcc
hey, i would like to know the latest stable version of gcc... i have went through the website.. waiting for the reply, vivek
Re: Doubt regarding gcc
2009/8/7 Mr. Vivek Varghese Jacob: > > i would like to know the latest stable version of gcc... > i have went through the website.. Did you miss the front page? And the releases page? If you still can't find the information* please send your question to gcc-h...@gcc.gnu.org instead. Jonathan * it's 4.4.1
Re: Doubt regarding gcc
Mr. Vivek Varghese Jacob wrote: > hey, > > i would like to know the latest stable version of gcc... > i have went through the website.. > > waiting for the reply, > > vivek There are two stable release branches maintained at any time, one current and one previous, and the most recent versions on each of those can be seen under the word "Status" in the right-hand of the two main columns on the front page at http://gcc.gnu.org/, where it shows you that 4.4.1 and 4.3.4 are the latest releases on the current and previous stable branches respectively. cheers, DaveK
Re: c-c++-common testsuite
On Fri, 7 Aug 2009, Dave Korn wrote: > Possibly we could modify the algorithm that enumerates directories matching > "$tool.*" to look for (e.g.) "*$tool.*" and then name directories like > "c.c++.dg"? The algorithm is hardcoded in core DejaGnu (runtest.exp). -- Joseph S. Myers jos...@codesourcery.com
regarding optimization options in phase ordering
Hi,
We've a problem here. we were trying to use cc1 with & without -O
option to verify the optimizations happening in our sample code. these r the
list of outputs after each compilation
without -O
p...@shiva:~/Desktop/Compilers/GCC/build/test$ ls
1.c1.c.011t.ehopt1.c.038t.release_ssa
1.c.001t.tu1.c.012t.eh 1.c.123t.optimized
1.c.003t.original 1.c.013t.cfg 1.c.125t.blocks
1.c.004t.gimple1.c.014t.cplxlower0 1.c.126t.final_cleanup
1.c.006t.vcg 1.c.015t.veclower 1.c.203t.statistics
1.c.007t.useless 1.c.021t.cleanup_cfg 1.s
1.c.010t.lower 1.c.023t.ssa a.out
with -O
1.c 1.c.051t.ccp2 1.c.085t.sink
1.c.001t.tu 1.c.052t.forwprop21.c.086t.loop
1.c.003t.original 1.c.054t.alias1.c.087t.loopinit
1.c.004t.gimple 1.c.055t.retslot 1.c.088t.copyprop4
1.c.006t.vcg 1.c.056t.phiprop 1.c.089t.dceloop1
1.c.007t.useless 1.c.057t.fre 1.c.090t.lim
1.c.010t.lower1.c.058t.copyprop21.c.093t.sccp
1.c.011t.ehopt1.c.059t.mergephi21.c.094t.empty
1.c.012t.eh 1.c.061t.dce1 1.c.099t.ivcanon
1.c.013t.cfg 1.c.062t.cselim 1.c.104t.cunroll
1.c.015t.veclower 1.c.063t.ifcombine1.c.107t.ivopts
1.c.021t.cleanup_cfg 1.c.064t.phiopt1 1.c.108t.loopdone
1.c.023t.ssa 1.c.066t.ch 1.c.111t.reassoc2
1.c.024t.early_optimizations 1.c.068t.cplxlower1.c.113t.dom2
1.c.025t.einline2 1.c.069t.sra 1.c.114t.phicprop2
1.c.026t.copyrename1 1.c.070t.copyrename3 1.c.115t.cddce2
1.c.027t.ccp1 1.c.071t.dom1 1.c.117t.dse2
1.c.028t.forwprop11.c.072t.phicprop11.c.118t.forwprop4
1.c.029t.addressables11.c.073t.dse1 1.c.119t.phiopt3
1.c.030t.esra 1.c.074t.reassoc1 1.c.121t.copyrename4
1.c.031t.copyprop11.c.075t.dce2 1.c.122t.uncprop
1.c.032t.mergephi11.c.076t.forwprop31.c.123t.optimized
1.c.033t.cddce1 1.c.077t.phiopt2 1.c.124t.nrv
1.c.034t.sdse 1.c.078t.objsz1.c.125t.blocks
1.c.036t.switchconv 1.c.079t.ccp3 1.c.126t.final_cleanup
1.c.037t.profile 1.c.080t.copyprop31.c.203t.statistics
1.c.038t.release_ssa 1.c.081t.fab 1.s
1.c.048t.addressables21.c.082t.sincos a.out
1.c.049t.copyrename2 1.c.083t.crited
But here, we tried to see the differences, until 1.c.027t.ccp1, the output
for the following source 1.c
#include
int main()
{
int a=5;
int b;
b=a;
printf("the number is :%d",b);
}
was 1.c.026t.copyrename1
;; Function main (main)
main ()
{
int b;
int a;
:
a_2 = b_1(D);
return;
}
but in 1.c.027t.ccp1, the output doesnot contain the actual assignment b=a.
;; Function main (main)
main ()
{
int b;
int a;
:
return;
}
We want to know, without b=a, how is it generating the final code for b=a
Kindly help
--
View this message in context:
http://www.nabble.com/regarding-optimization-options-in-phase-ordering-tp24863416p24863416.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: regarding optimization options in phase ordering
On Fri, Aug 7, 2009 at 1:50 PM, pms wrote:
>
> Hi,
> We've a problem here. we were trying to use cc1 with & without -O
> option to verify the optimizations happening in our sample code. these r the
> list of outputs after each compilation
> without -O
> p...@shiva:~/Desktop/Compilers/GCC/build/test$ ls
> 1.c 1.c.011t.ehopt 1.c.038t.release_ssa
> 1.c.001t.tu 1.c.012t.eh 1.c.123t.optimized
> 1.c.003t.original 1.c.013t.cfg 1.c.125t.blocks
> 1.c.004t.gimple 1.c.014t.cplxlower0 1.c.126t.final_cleanup
> 1.c.006t.vcg 1.c.015t.veclower 1.c.203t.statistics
> 1.c.007t.useless 1.c.021t.cleanup_cfg 1.s
> 1.c.010t.lower 1.c.023t.ssa a.out
>
> with -O
>
> 1.c 1.c.051t.ccp2 1.c.085t.sink
> 1.c.001t.tu 1.c.052t.forwprop2 1.c.086t.loop
> 1.c.003t.original 1.c.054t.alias 1.c.087t.loopinit
> 1.c.004t.gimple 1.c.055t.retslot 1.c.088t.copyprop4
> 1.c.006t.vcg 1.c.056t.phiprop 1.c.089t.dceloop1
> 1.c.007t.useless 1.c.057t.fre 1.c.090t.lim
> 1.c.010t.lower 1.c.058t.copyprop2 1.c.093t.sccp
> 1.c.011t.ehopt 1.c.059t.mergephi2 1.c.094t.empty
> 1.c.012t.eh 1.c.061t.dce1 1.c.099t.ivcanon
> 1.c.013t.cfg 1.c.062t.cselim 1.c.104t.cunroll
> 1.c.015t.veclower 1.c.063t.ifcombine 1.c.107t.ivopts
> 1.c.021t.cleanup_cfg 1.c.064t.phiopt1 1.c.108t.loopdone
> 1.c.023t.ssa 1.c.066t.ch 1.c.111t.reassoc2
> 1.c.024t.early_optimizations 1.c.068t.cplxlower 1.c.113t.dom2
> 1.c.025t.einline2 1.c.069t.sra 1.c.114t.phicprop2
> 1.c.026t.copyrename1 1.c.070t.copyrename3 1.c.115t.cddce2
> 1.c.027t.ccp1 1.c.071t.dom1 1.c.117t.dse2
> 1.c.028t.forwprop1 1.c.072t.phicprop1 1.c.118t.forwprop4
> 1.c.029t.addressables1 1.c.073t.dse1 1.c.119t.phiopt3
> 1.c.030t.esra 1.c.074t.reassoc1 1.c.121t.copyrename4
> 1.c.031t.copyprop1 1.c.075t.dce2 1.c.122t.uncprop
> 1.c.032t.mergephi1 1.c.076t.forwprop3 1.c.123t.optimized
> 1.c.033t.cddce1 1.c.077t.phiopt2 1.c.124t.nrv
> 1.c.034t.sdse 1.c.078t.objsz 1.c.125t.blocks
> 1.c.036t.switchconv 1.c.079t.ccp3 1.c.126t.final_cleanup
> 1.c.037t.profile 1.c.080t.copyprop3 1.c.203t.statistics
> 1.c.038t.release_ssa 1.c.081t.fab 1.s
> 1.c.048t.addressables2 1.c.082t.sincos a.out
> 1.c.049t.copyrename2 1.c.083t.crited
>
> But here, we tried to see the differences, until 1.c.027t.ccp1, the output
> for the following source 1.c
> #include
> int main()
>
> {
> int a=5;
> int b;
> b=a;
> printf("the number is :%d",b);
> }
>
> was 1.c.026t.copyrename1
> ;; Function main (main)
>
> main ()
> {
> int b;
> int a;
>
> :
> a_2 = b_1(D);
> return;
>
> }
> but in 1.c.027t.ccp1, the output doesnot contain the actual assignment b=a.
> ;; Function main (main)
>
> main ()
> {
> int b;
> int a;
>
> :
> return;
>
> }
>
> We want to know, without b=a, how is it generating the final code for b=a
Nothing. Because it's a dead statement.
Richard.
> Kindly help
>
> --
> View this message in context:
> http://www.nabble.com/regarding-optimization-options-in-phase-ordering-tp24863416p24863416.html
> Sent from the gcc - Dev mailing list archive at Nabble.com.
>
>
PRE_DEC, POST_INC
Hi, I am working on a new port. The target machine supports post-increment and pre-decrement addressing modes. These modes are twice faster than indexed mode. It is important for us that GCC consider them well. I wrote emails to gcc-help and I was told that GCC was not so good at pre/post-dec/increment since few targets support these modes. I would like to know if there is a good way to make pre-dec and post-inc modes have more priority than indexed mode. Is there current work for dealing with this issue ? Thank you. Regards. Florent
Re: gcc git's performance problem Fwd: git gc expanding packed data?
Hi - Nicolas wrote: > Anyone has an idea of the git version running on gcc.gnu.org? It is > certainly buggy and needs fixing. It was 1.6.3.2 now it's 1.6.4, practically spring chickens. > Anyway... To solve your problem, you simply need to run 'git gc' with > the --prune=now [...] > And BTW, using 'git gc --aggressive' with a later git version (or > 'git repack -a -f -d --window=250 --depth=250') gives me a .git/objects > directory size of 310 MB [...] Unfortunately, git gc --aggressive / repack proceed consume several gigabytes of memory, which on the 32-bit host sometimes fails. - FChE
Re: regarding optimization options in phase ordering
thanks, But b=a is a assignment statement. It is doing some memory operations
isn't it. Assuming b=a is a dead statement, how r the following i386
assembly statements generated
pushl %ebp
movl%esp, %ebp
andl$-16, %esp
subl$16, %esp
movl$5, 4(%esp)
movl$.LC0, (%esp)
callprintf
pls reply
Richard Guenther-2 wrote:
>
> On Fri, Aug 7, 2009 at 1:50 PM, pms wrote:
>>
>> Hi,
>> We've a problem here. we were trying to use cc1 with & without -O
>> option to verify the optimizations happening in our sample code. these r
>> the
>> list of outputs after each compilation
>> without -O
>> p...@shiva:~/Desktop/Compilers/GCC/build/test$ ls
>> 1.c 1.c.011t.ehopt 1.c.038t.release_ssa
>> 1.c.001t.tu 1.c.012t.eh 1.c.123t.optimized
>> 1.c.003t.original 1.c.013t.cfg 1.c.125t.blocks
>> 1.c.004t.gimple 1.c.014t.cplxlower0 1.c.126t.final_cleanup
>> 1.c.006t.vcg 1.c.015t.veclower 1.c.203t.statistics
>> 1.c.007t.useless 1.c.021t.cleanup_cfg 1.s
>> 1.c.010t.lower 1.c.023t.ssa a.out
>>
>> with -O
>>
>> 1.c 1.c.051t.ccp2 1.c.085t.sink
>> 1.c.001t.tu 1.c.052t.forwprop2 1.c.086t.loop
>> 1.c.003t.original 1.c.054t.alias 1.c.087t.loopinit
>> 1.c.004t.gimple 1.c.055t.retslot 1.c.088t.copyprop4
>> 1.c.006t.vcg 1.c.056t.phiprop 1.c.089t.dceloop1
>> 1.c.007t.useless 1.c.057t.fre 1.c.090t.lim
>> 1.c.010t.lower 1.c.058t.copyprop2 1.c.093t.sccp
>> 1.c.011t.ehopt 1.c.059t.mergephi2 1.c.094t.empty
>> 1.c.012t.eh 1.c.061t.dce1 1.c.099t.ivcanon
>> 1.c.013t.cfg 1.c.062t.cselim 1.c.104t.cunroll
>> 1.c.015t.veclower 1.c.063t.ifcombine 1.c.107t.ivopts
>> 1.c.021t.cleanup_cfg 1.c.064t.phiopt1 1.c.108t.loopdone
>> 1.c.023t.ssa 1.c.066t.ch 1.c.111t.reassoc2
>> 1.c.024t.early_optimizations 1.c.068t.cplxlower 1.c.113t.dom2
>> 1.c.025t.einline2 1.c.069t.sra 1.c.114t.phicprop2
>> 1.c.026t.copyrename1 1.c.070t.copyrename3 1.c.115t.cddce2
>> 1.c.027t.ccp1 1.c.071t.dom1 1.c.117t.dse2
>> 1.c.028t.forwprop1 1.c.072t.phicprop1 1.c.118t.forwprop4
>> 1.c.029t.addressables1 1.c.073t.dse1 1.c.119t.phiopt3
>> 1.c.030t.esra 1.c.074t.reassoc1 1.c.121t.copyrename4
>> 1.c.031t.copyprop1 1.c.075t.dce2 1.c.122t.uncprop
>> 1.c.032t.mergephi1 1.c.076t.forwprop3 1.c.123t.optimized
>> 1.c.033t.cddce1 1.c.077t.phiopt2 1.c.124t.nrv
>> 1.c.034t.sdse 1.c.078t.objsz 1.c.125t.blocks
>> 1.c.036t.switchconv 1.c.079t.ccp3
>> 1.c.126t.final_cleanup
>> 1.c.037t.profile 1.c.080t.copyprop3 1.c.203t.statistics
>> 1.c.038t.release_ssa 1.c.081t.fab 1.s
>> 1.c.048t.addressables2 1.c.082t.sincos a.out
>> 1.c.049t.copyrename2 1.c.083t.crited
>>
>> But here, we tried to see the differences, until 1.c.027t.ccp1, the
>> output
>> for the following source 1.c
>> #include
>> int main()
>>
>> {
>> int a=5;
>> int b;
>> b=a;
>> printf("the number is :%d",b);
>> }
>>
>> was 1.c.026t.copyrename1
>> ;; Function main (main)
>>
>> main ()
>> {
>> int b;
>> int a;
>>
>> :
>> a_2 = b_1(D);
>> return;
>>
>> }
>> but in 1.c.027t.ccp1, the output doesnot contain the actual assignment
>> b=a.
>> ;; Function main (main)
>>
>> main ()
>> {
>> int b;
>> int a;
>>
>> :
>> return;
>>
>> }
>>
>> We want to know, without b=a, how is it generating the final code for b=a
>
> Nothing. Because it's a dead statement.
>
> Richard.
>
>> Kindly help
>>
>> --
>> View this message in context:
>> http://www.nabble.com/regarding-optimization-options-in-phase-ordering-tp24863416p24863416.html
>> Sent from the gcc - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/regarding-optimization-options-in-phase-ordering-tp24863416p24864601.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: PRE_DEC, POST_INC
On Fri, Aug 7, 2009 at 1:33 PM, Florent Defay wrote:
> Hi,
>
> I am working on a new port.
>
> The target machine supports post-increment and pre-decrement
> addressing modes. These modes are twice faster than indexed mode.
> It is important for us that GCC consider them well.
GCC does support generation of pre{post}-inc {dec}. GCC's auto-inc
detector works at a basic block level and attempts to generate
auto-inc operations within a basic block . Look at auto-inc-dec.c for
more information.It is an area which could do with some improvement
and work , however no one's found the time to do it yet.
>
> I wrote emails to gcc-help and I was told that GCC was not so good at
> pre/post-dec/increment since few targets support these modes.
>
> I would like to know if there is a good way to make pre-dec and
> post-inc modes have more priority than indexed mode.
> Is there current work for dealing with this issue ?
I am assuming you already have basic generation of auto-incs and you
have your definitions for legitimate{legitimize}_address all set up
correctly.
In this case you could start by tweaking your address costs macros.
Getting that right can help you get going in the right direction with
the current state of the art. In a previous life while maintaining a
private port of GCC I've dabbled with a few patches posted by Joern
Reneccke with regards to auto-inc-dec that worked well for me in
improving code generation on some of the benchmarks. You should be
able to get them out using Google.
There are a number of bugzilla entries in the database that cover a
number of cases for auto-inc generation and some ideas on what can be
done to improve this. You might be better off searching in that as
well. One of the problems upto 4.3 was that the ivopts and the loop
optimizers didn't care too much about auto-increment addressing and
thereby pessimizing this in favour of using index addressing. There
have been a few patches that were being discussed in in the recent
past by Bernd Schmidt and Zdenek attempting to address auto-inc
generation for loop ivopts but I'm not sure if these have gone into
trunk yet.
Hope this helps.
cheers
Ramana
RE: PRE_DEC, POST_INC
I asked similar question regarding PRE_INC/POST_INC quite a while ago,
and there were quite some discussions. Haven't check whether the situation
changed.
http://gcc.gnu.org/ml/gcc/2007-11/msg00032.html
Bingfeng Mei
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Ramana Radhakrishnan
> Sent: 07 August 2009 14:11
> To: Florent Defay
> Cc: gcc@gcc.gnu.org
> Subject: Re: PRE_DEC, POST_INC
>
> On Fri, Aug 7, 2009 at 1:33 PM, Florent
> Defay wrote:
> > Hi,
> >
> > I am working on a new port.
> >
> > The target machine supports post-increment and pre-decrement
> > addressing modes. These modes are twice faster than indexed mode.
> > It is important for us that GCC consider them well.
>
>
> GCC does support generation of pre{post}-inc {dec}. GCC's auto-inc
> detector works at a basic block level and attempts to generate
> auto-inc operations within a basic block . Look at auto-inc-dec.c for
> more information.It is an area which could do with some improvement
> and work , however no one's found the time to do it yet.
>
> >
> > I wrote emails to gcc-help and I was told that GCC was not
> so good at
> > pre/post-dec/increment since few targets support these modes.
> >
> > I would like to know if there is a good way to make pre-dec and
> > post-inc modes have more priority than indexed mode.
> > Is there current work for dealing with this issue ?
>
> I am assuming you already have basic generation of auto-incs and you
> have your definitions for legitimate{legitimize}_address all set up
> correctly.
>
> In this case you could start by tweaking your address costs macros.
> Getting that right can help you get going in the right direction with
> the current state of the art. In a previous life while maintaining a
> private port of GCC I've dabbled with a few patches posted by Joern
> Reneccke with regards to auto-inc-dec that worked well for me in
> improving code generation on some of the benchmarks. You should be
> able to get them out using Google.
>
> There are a number of bugzilla entries in the database that cover a
> number of cases for auto-inc generation and some ideas on what can be
> done to improve this. You might be better off searching in that as
> well. One of the problems upto 4.3 was that the ivopts and the loop
> optimizers didn't care too much about auto-increment addressing and
> thereby pessimizing this in favour of using index addressing. There
> have been a few patches that were being discussed in in the recent
> past by Bernd Schmidt and Zdenek attempting to address auto-inc
> generation for loop ivopts but I'm not sure if these have gone into
> trunk yet.
>
> Hope this helps.
>
>
> cheers
> Ramana
>
>
Re: c-c++-common testsuite
On Thu, Aug 06, 2009 at 05:38:01PM -0700, Janis Johnson wrote: > I've been thinking about that lately, it would be useful for several > kinds of functionality. We'd want effective targets for the language > for using different options and for providing different error/warning > checks for each language. I haven't looked into how to handle it with > DejaGnu, maybe something like gcc.shared and a [symbolic] link to it > called g++.shared; do links work with Subversion? It should be easy with DejaGNU; does changing $tests in e.g. g++.dg/dg.exp successfully pick up files from another directory? -- Daniel Jacobowitz CodeSourcery
Re: c-c++-common testsuite
2009/8/7 Janis Johnson :
> On Fri, 2009-08-07 at 00:06 +0200, Manuel López-Ibáñez wrote:
>> Often I want to test the exactly same testcase in C and C++, so I find
>> myself adding duplicate tests under gcc.dg/ and g++.dg/. Would it be
>> possible to have a shared testsuite dir that is run for both C and C++
>> languages? (possibly with different default configurations, like
>> adding -Wc++-compat to the commandline for C runs).
>
> I've been thinking about that lately, it would be useful for several
> kinds of functionality. We'd want effective targets for the language
> for using different options and for providing different error/warning
> checks for each language. I haven't looked into how to handle it with
> DejaGnu, maybe something like gcc.shared and a [symbolic] link to it
> called g++.shared; do links work with Subversion?
Janis, it would be extremely useful to have dg-options that are only
enabled for certain languages, so I can do
/* { dg-options "-std=c99" { dg-require-effective-target c } } */
/* { dg-options "" { dg-require-effective-target c++ } } */
Would this be hard to implement? Any ideas?
As for how to run the shared tests, Joseph suggestion works, but I
think it is better to just run the common tests from each dg.exp file
Index: gcc/testsuite/gcc.dg/dg.exp
===
--- gcc/testsuite/gcc.dg/dg.exp (revision 150491)
+++ gcc/testsuite/gcc.dg/dg.exp (working copy)
@@ -30,7 +30,11 @@ dg-init
# Main loop.
dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cSi\]]] \
"" $DEFAULT_CFLAGS
+# C/C++ common tests.
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/*.\[cSi\]]] \
+ " -Wc++-compat " ""
+
# All done.
dg-finish
Index: gcc/testsuite/g++.dg/dg.exp
===
--- gcc/testsuite/g++.dg/dg.exp (revision 150491)
+++ gcc/testsuite/g++.dg/dg.exp (working copy)
@@ -47,7 +47,11 @@ set tests [prune $tests $srcdir/$subdir/
set tests [prune $tests $srcdir/$subdir/graphite/*]
# Main loop.
dg-runtest $tests "" $DEFAULT_CXXFLAGS
+# C/C++ common tests.
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/*.\[cSi\]]] \
+ "" ""
+
# All done.
dg-finish
so people can run c-c++-common testcases by doing simply
make -C gcc check-gcc RUNTESTFLAGS=dg.exp='*Wconversion*'
Cheers,
Manuel.
Asymmetry of user-difined swap and distance
Hi,
Let's have a look at std::pair<>::swap and std::lower_bound<> implementations.
1. pair::swap in
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_pair.h?view=markup
void
swap(pair& __p)
{
using std::swap;
swap(first, __p.first);
swap(second, __p.second);
}
2. lower_bound in
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_algo.h?view=markup
_DistanceType __len = std::distance(__first, __last);
Now we need to use user-defined versions of swap and distance for corresponding
types when we work with STL.
It means that swap for user types could be defined either in std namespace or in the user type namespace (argument-dependent name
lookup).
On the other hand, distance (advance, etc.) for user types must be defined in
std namespace.
How come? Why this asymmetry?
Should we always extend std namespace?
Regards,
Maxim P. Dementiev
Re: c-c++-common testsuite
On Fri, 2009-08-07 at 15:48 +0200, Manuel López-Ibáñez wrote:
> Janis, it would be extremely useful to have dg-options that are only
> enabled for certain languages, so I can do
>
> /* { dg-options "-std=c99" { dg-require-effective-target c } } */
> /* { dg-options "" { dg-require-effective-target c++ } } */
>
> Would this be hard to implement? Any ideas?
This seems to work fine (added to target-supports.exp), except that
you'd use them in your example as just "c" and "c++".
# Return 1 if the language for the compiler under test is C.
proc check_effective_target_c { } {
global tool
if [string match $tool "gcc"] {
return 1
}
return 0
}
# Return 1 if the language for the compiler under test is C++.
proc check_effective_target_c++ { } {
global tool
if [string match $tool "g++"] {
return 1
}
return 0
}
Re: Asymmetry of user-difined swap and distance
2009/8/7 Maxim Dementiev: > > It means that swap for user types could be defined either in std namespace > or in the user type namespace (argument-dependent name lookup). Yes, this is intentional. swap() is a point of customisation point, see http://www.ddj.com/cpp/184401876 and the definition in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html > On the other hand, distance (advance, etc.) for user types must be defined > in std namespace. There is no need to customise std::distance(), or certainly a lot less need, because the Standard Library can provide optimal implementations for all possible iterator categories. The generic swap() function in namespace std won't even work with some types and is sub-optimal for others. Jonathan
Re: Asymmetry of user-difined swap and distance
On Fri, 7 Aug 2009 19:19:03 +0100 Jonathan Wakely wrote: 2009/8/7 Maxim Dementiev: It means that swap for user types could be defined either in std namespace or in the user type namespace (argument-dependent name lookup). Yes, this is intentional. swap() is a point of customisation point, see http://www.ddj.com/cpp/184401876 and the definition in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html Ok. Thanks! On the other hand, distance (advance, etc.) for user types must be defined in std namespace. There is no need to customise std::distance(), or certainly a lot less need, because the Standard Library can provide optimal implementations for all possible iterator categories. The generic swap() function in Dear Jonathan, what about structures like B-Trees where the speed is equal to random iterators on one node but is lesser when you iterates though different nodes? So, for me the question isn't "Do I really need it?" But "Shall I extend the std namespace?" Yours faithfully, Max
Re: Notes toward re-implementing EH in gimple
On 08/06/2009 12:35 PM, Richard Henderson wrote:
{ exc_ptr, filter } = EH_LANDING_PAD;
Placeholder for the landing-pad rtl. Has 2 outputs
for both the exception pointer and the filter.
I'm going to drop this construct. Instead, I'm going to mark
the label, and have the landing pad code be emitted as it
currently is by the rtl. This will prevent any problems with
the landing pad code being moved away from the start of the
block.
I'm going to adjust the rtl code so that it generates different
pseudos for exc_ptr and filter for each region. These will be
accessible from gimple with the EXC_PTR_EXPR and FILTER_EXPR
tree codes.
EXC_PTR_EXPR and FILTER_EXPR will be expanded to take the EH
region number as a parameter. Since they no longer need to be
saved and restored, they will no longer be gimple lvalues.
In gimple, the landing pad will be generated as
L.N:
exc_ptr.1 = EXC_PTR_EXPR (N);
filter.1 = FILTER_EXPR (N);
ie, copied into normal variables for use. These can be moved
about, or deleted, as the optimizer desires.
All of this seems much cleaner than what I initially imagined.
r~
Re: Notes toward re-implementing EH in gimple
On Fri, Aug 7, 2009 at 9:22 PM, Richard Henderson wrote:
> On 08/06/2009 12:35 PM, Richard Henderson wrote:
>>
>> { exc_ptr, filter } = EH_LANDING_PAD;
>>
>> Placeholder for the landing-pad rtl. Has 2 outputs
>> for both the exception pointer and the filter.
>
> I'm going to drop this construct. Instead, I'm going to mark
> the label, and have the landing pad code be emitted as it
> currently is by the rtl. This will prevent any problems with
> the landing pad code being moved away from the start of the
> block.
>
> I'm going to adjust the rtl code so that it generates different
> pseudos for exc_ptr and filter for each region. These will be
> accessible from gimple with the EXC_PTR_EXPR and FILTER_EXPR
> tree codes.
>
> EXC_PTR_EXPR and FILTER_EXPR will be expanded to take the EH
> region number as a parameter. Since they no longer need to be
> saved and restored, they will no longer be gimple lvalues.
>
> In gimple, the landing pad will be generated as
>
> L.N:
> exc_ptr.1 = EXC_PTR_EXPR (N);
> filter.1 = FILTER_EXPR (N);
Will exc_ptr.1 and filter.1 be gimple registers? Does the above have
virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR
or FILTER_EXPR load?
Can we CSE FILTER_EXPR (N) and EXC_PTR_EXPR (N)?
> ie, copied into normal variables for use. These can be moved
> about, or deleted, as the optimizer desires.
>
> All of this seems much cleaner than what I initially imagined.
Thanks for cleaning this up.
Richard.
>
> r~
>
>
Re: Notes toward re-implementing EH in gimple
On 08/07/2009 12:31 PM, Richard Guenther wrote: L.N: exc_ptr.1 = EXC_PTR_EXPR (N); filter.1 = FILTER_EXPR (N); Will exc_ptr.1 and filter.1 be gimple registers? Yes. Does the above have virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR or FILTER_EXPR load? No and no. They will eventually resolve to pseudos generated during rtl eh expansion. But to avoid silliness at the gimple level I don't want to allow them to appear at random. Ideally, the rtl would generate what it needs directly into exc_ptr.1, but I couldn't figure out any way to do that cleanly. In the end, generating an extra pseudo for register allocation to coalesce is not the worst sin I could commit here. Can we CSE FILTER_EXPR (N) and EXC_PTR_EXPR (N)? Yes. r~
