[g++ 4.4] Unicode string literal support?
http://gcc.gnu.org/projects/cxx0x.html shows Unicode string literals (N2442) as
being supported in gcc 4.4. But this little program fails to compile:
#include
int main()
{
std::cout << u8"foo" << std::endl;
}
C:\gcc>bin\g++ -std=gnu++0x u8-literal.cpp
u8-literal.cpp: In function 'int main()':
u8-literal.cpp:5: error: 'u8' was not declared in this scope
u8-literal.cpp:5: error: expected ';' before string constant
C:\gcc>bin\g++ -v
Built by Equation Solution .
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.4.1-mingw/configure --host=i386-pc-mingw32
--build=x86_64-unknown-linux-gn
u --target=i386-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.4.1 -
-with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls
--disable-tls --with-gmp=/home/
gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw3
2/native/x86_32/mpfr --enable-languages=c,fortran,c++
--with-sysroot=/home/gfortran/gcc-home/binary/
mingw32/cross/x86_32/gcc/4.4.1 --enable-libgomp --enable-threads=win32
--disable-win32-registry
Thread model: win32
gcc version 4.4.1 (GCC)
Is this a bug in gcc? A bug in the C++0x Support page? A bug in my test?
Thanks for all the great work on C++0x!
--Beman
Re: [g++ 4.4] Unicode string literal support?
Hi Beman
> http://gcc.gnu.org/projects/cxx0x.html shows Unicode string literals (N2442)
> as
> being supported in gcc 4.4. But this little program fails to compile:
>
> #include
> int main()
> {
> std::cout << u8"foo" << std::endl;
> }
>
...
> Is this a bug in gcc? A bug in the C++0x Support page? A bug in my test?
>
To my best knowledge the feature is not implemented at all, thus a bug
in the C++0x Support page.
Paolo.
loop optimization in gcc
Hi All, I have been studying the gcc code lately as part of my project.I have got info from this mailing list about CFG and DFG information.I want to know how gcc uses this information to perform loop optimization? Does it Follow any particular algorithm or in particular what are the different techniques that it uses to parallelize the code by performing the loop optimizations?(correct me please if this sentence is not right). If possible please provide any pointers to any form of literature available regarding it. Thanks in advance. -- cheers sandy
Re: Escape the unnecessary re-optimization in automatic parallelization.
Hi Joern, On Sat, Oct 10, 2009 at 5:27 PM, Joern Rennecke wrote: > Quoting Li Feng : >> >> So my question is, >> >> 1. Is this necessary/correct if we want to escape the re-optimization for >> the >> first few passes before tree-parloop.c and continue the optimization >> passes >> after it for the function fun.loop_f0, there must be compile time savings >> if we >> do this in my opinion. > > Note that the process of parallelization adds new code, and make > pre-existing code makes code sub-optimal - e.g. it transforms the loop into > a normal form > where there is only one induction variable. > > So, even if you have a homogeneous sets of cores that you are targeting, it > makes sense in principle to re-start optimizations from the beginning. > If the re-running of each individual optimization pass makes sense will > depend > on what that pass exactly does and how that relates to parallelized loop and > the target. > > However, parallelization is done to differetn target architectures, then > re-running the optimization becomes more improtant, since different > parameters > and heuristics can come into play. I agree that re-running will take difference parameters and heuristics come into play. But I'm not clear about re-running the first few passes will do optimizations for different target architectures for parallelization. shouldn't such kind optimizations be done at back-end ? I mean, since the first few passes before autopar is in the middle end. > > Moreover, the set of optimization passes that run before parallelization is > subject to change as GCC evolves. > Yes. I agree. > Therefore, the most effective way to address the issue of running redundant > optimization passes in the context is probably to put it in the wider > context > of the work to allow external plugins to influence the pass sequence that is > being applied, and to control this with machine learning. > Thanks, Li
building LTO plugin fails for x86_64-unknown -linux-gnu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 libtool: link: gcc -shared .libs/lto-plugin.o - -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64 - -lelf - -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.5.0/gcc-4.5.0/libiberty/pic - -liberty-Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0 /opt/devel/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.1/bin/ld: /SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64/libiberty.a(argv.o): relocation R_X86_64_32S against `_sch_istable' can not be used when making a shared object; recompile with -fPIC /SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64/libiberty.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[3]: *** [liblto_plugin.la] Error 1 gmake[3]: Leaving directory `/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.5.0/gcc-4.5.0/lto-plugin' Does anybody else sees this? Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrSAicACgkQoUhjsh59BL5XagCfb9ZVHFrpUVx/tvyUrZI+getK quUAn3nR+7iR0YCD83pAOX7ekFGOkAuA =3bqW -END PGP SIGNATURE-
C++ Plugins
(Version 4.5.0) There are plugin callbacks which trigger at the end of processing types and C++ functions, but I can not find a clean way for plugin code to notice a top-level variable declaration. I'm hoping that the answer does not require the plugin shared library to bind to global symbols of the compiler (i.e. global_namespace). TIA - Terrence Miller
Re: building LTO plugin fails for x86_64-unknown -linux-gnu
On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > libtool: link: gcc -shared .libs/lto-plugin.o > - > -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64 is there a libiberty in that path? > - -lelf > - > -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.5.0/gcc-4.5.0/libiberty/pic it's supposed to be picked up from here instead. Richard. > - -liberty -Wl,-soname -Wl,liblto_plugin.so.0 -o > .libs/liblto_plugin.so.0.0.0 > /opt/devel/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.1/bin/ld: > /SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64/libiberty.a(argv.o): > relocation R_X86_64_32S against `_sch_istable' can not be used when making a > shared object; recompile with -fPIC > /SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64/libiberty.a: > could not read symbols: Bad value > collect2: ld returned 1 exit status > gmake[3]: *** [liblto_plugin.la] Error 1 > gmake[3]: Leaving directory > `/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.5.0/gcc-4.5.0/lto-plugin' > > > Does anybody else sees this? > > Rainer > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrSAicACgkQoUhjsh59BL5XagCfb9ZVHFrpUVx/tvyUrZI+getK > quUAn3nR+7iR0YCD83pAOX7ekFGOkAuA > =3bqW > -END PGP SIGNATURE- >
Re: building LTO plugin fails for x86_64-unknown -linux-gnu
On Sun, Oct 11, 2009 at 6:21 PM, Richard Guenther wrote: > On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> libtool: link: gcc -shared .libs/lto-plugin.o >> - >> -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64 > > is there a libiberty in that path? > >> - -lelf >> - >> -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.5.0/gcc-4.5.0/libiberty/pic > > it's supposed to be picked up from here instead. Thus, I guess Index: lto-plugin/Makefile.am === --- lto-plugin/Makefile.am (revision 152638) +++ lto-plugin/Makefile.am (working copy) @@ -16,4 +16,4 @@ AM_CFLAGS = -Wall -Werror libexecsub_LTLIBRARIES = liblto_plugin.la liblto_plugin_la_SOURCES = lto-plugin.c -liblto_plugin_la_LIBADD = $(LIBELFLIBS) -L../libiberty/pic -liberty +liblto_plugin_la_LIBADD = $(LIBELFLIBS) ../libiberty/pic/libiberty.a would fix it. Richard.
Re: [g++ 4.4] Unicode string literal support?
Hi again, > To my best knowledge the feature is not implemented at all, thus a bug > in the C++0x Support page. Following up to my previous message, I figured out a probable reason for the mistake: actually we *do* have a patch implementing the feature, which however has not been applied yet to mainline, see the threads: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01099.html http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00158.html At this point however, it's safe to say that the feature isn't available in 4.4, I committed the below. Paolo. / 2009-10-11 Paolo Carlini * htdocs/gcc-4.4/cxx0x_status.html: Unicode string literals are unsupported in 4.4. Index: htdocs/gcc-4.4/cxx0x_status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/cxx0x_status.html,v retrieving revision 1.10 diff -u -r1.10 cxx0x_status.html --- htdocs/gcc-4.4/cxx0x_status.html2 Oct 2009 20:52:15 - 1.10 +++ htdocs/gcc-4.4/cxx0x_status.html11 Oct 2009 17:31:19 - @@ -195,7 +195,7 @@ Unicode string literals http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm";>N2442 - Yes + No Raw string literals
Re: [g++ 4.4] Unicode string literal support?
On Sun, Oct 11, 2009 at 7:31 AM, Paolo Carlini wrote:
> Hi Beman
>> http://gcc.gnu.org/projects/cxx0x.html shows Unicode string literals (N2442)
>> as
>> being supported in gcc 4.4. But this little program fails to compile:
>>
>> #include
>> int main()
>> {
>> std::cout << u8"foo" << std::endl;
>> }
>>
> ...
>> Is this a bug in gcc? A bug in the C++0x Support page? A bug in my test?
>>
> To my best knowledge the feature is not implemented at all, thus a bug
> in the C++0x Support page.
Actually the front-end support is implemented but it is just u"foo"
(for UTF-8) and U"foo" (for UTF-16). The library support is not there
though and you just get operator<<(void const*) .
Thanks,
Andrew Pinski
Re: [g++ 4.4] Unicode string literal support?
On Sun, Oct 11, 2009 at 10:36 AM, Paolo Carlini wrote: > Hi again, >> To my best knowledge the feature is not implemented at all, thus a bug >> in the C++0x Support page. > Following up to my previous message, I figured out a probable reason for > the mistake: actually we *do* have a patch implementing the feature, > which however has not been applied yet to mainline, see the threads: > > http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01099.html > http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00158.html > > At this point however, it's safe to say that the feature isn't available > in 4.4, I committed the below. That is about Raw strings. u and U support is there, u8 is not there yet. So we don't fully support this N. -- Pinski
Re: [g++ 4.4] Unicode string literal support?
On Sun, Oct 11, 2009 at 10:42:41AM -0700, Andrew Pinski wrote: > On Sun, Oct 11, 2009 at 10:36 AM, Paolo Carlini > wrote: > > Hi again, > >> To my best knowledge the feature is not implemented at all, thus a bug > >> in the C++0x Support page. > > Following up to my previous message, I figured out a probable reason for > > the mistake: actually we *do* have a patch implementing the feature, > > which however has not been applied yet to mainline, see the threads: > > > > http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01099.html > > http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00158.html > > > > At this point however, it's safe to say that the feature isn't available > > in 4.4, I committed the below. > > That is about Raw strings. u and U support is there, u8 is not there > yet. So we don't fully support this N. The above mentioned patch adds support for raw strings and u8. Jakub
Re: [g++ 4.4] Unicode string literal support?
Jakub Jelinek wrote: > The above mentioned patch adds support for raw strings and u8. > Indeed. I have just committed the below too. Paolo. // 2009-10-11 Paolo Carlini * htdocs/projects/cxx0x_status.html: Unicode string literals are unsupported in 4.4. Index: htdocs/projects/cxx0x.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx0x.html,v retrieving revision 1.28 diff -u -r1.28 cxx0x.html --- htdocs/projects/cxx0x.html 10 Oct 2009 01:06:00 - 1.28 +++ htdocs/projects/cxx0x.html 11 Oct 2009 18:00:03 - @@ -219,7 +219,7 @@ Unicode string literals http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm";>N2442 - GCC 4.4 + No[http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01099.html";>Patch] Raw string literals
Re: delete dead feature branches?
On Fri, 2009-09-25 at 16:55 +, Joseph S. Myers wrote: > Do we believe any future conversion to another version control system > (that might have a more structured notion of what is a branch than it > simply being a directory used in a certain way) would continue to make the > history of such branches readily available? If that happens to be true with some future version control system, couldn't we restore the deleted branches before running whatever conversion tool exists? Ben -- Ben Elliston Australia Development Lab, IBM
gcc-4.3-20091011 is now available
Snapshot gcc-4.3-20091011 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20091011/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 152651 You'll find: gcc-4.3-20091011.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20091011.tar.bz2 C front end and core compiler gcc-ada-4.3-20091011.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20091011.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20091011.tar.bz2 C++ front end and runtime gcc-java-4.3-20091011.tar.bz2 Java front end and runtime gcc-objc-4.3-20091011.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20091011.tar.bz2The GCC testsuite Diffs from 4.3-20091004 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: loop optimization in gcc
sandeep soni writes: > I have been studying the gcc code lately as part of my project.I have > got info from this mailing list about CFG and DFG information.I want > to know how gcc uses this information to perform loop optimization? > Does it Follow any particular algorithm or in particular what are the > different techniques that it uses to parallelize the code by > performing the loop optimizations?(correct me please if this sentence > is not right). I'm not really sure what you are asking. gcc supports OpenMP for parallelizing loops. That is mostly done in the frontends. I don't think it has much to do with the CFG or DFG, but I'm not very familiar with the code. The other loop optimizations are mostly in tree-ssa-loop-*.c, q.v. Ian
