Re: Is this power gcc bug?
You are right, it's my fault. thanks a lot Carrot On Fri, Mar 29, 2013 at 6:33 PM, Alan Modra wrote: > On Fri, Mar 29, 2013 at 04:58:50PM -0700, Carrot Wei wrote: >> /trunkbin/bin/gcc -c -o rtl.o -DSPEC_CPU -DNDEBUG -I. -O2 >> -DSPEC_CPU_LP64 -m32rtl.c > > You've given contradictory options. -m32 is *not* LP64. > >> The left shift count is 32, it is actually less than the width of >> unsigned long 64. > > Nope, unsigned long is 32 bits for -m32. > > -- > Alan Modra > Australia Development Lab, IBM
Trying to find a link for information about parsing template parameters and the >> problem
Hey guys, I'm still planning to rewrite the c++ parser in GCC, right now I am still researching, I remember a page that talked about the problems of parsing > in nested templates, and I cannot find the link! Searching for it has yielded people asking questions about errors where >> occurs. Please provide me with the link. Alec
Re: Trying to find a link for information about parsing template parameters and the >> problem
On Mon, Apr 1, 2013 at 8:55 AM, Alec Teal wrote: > > I'm still planning to rewrite the c++ parser in GCC, right now I am still > researching, I remember a page that talked about the problems of parsing > in > nested templates, and I cannot find the link! > > Searching for it has yielded people asking questions about errors where >> > occurs. > > Please provide me with the link. I'm not sure this kind of message really belongs on the gcc@gcc.gnu.org mailing list, which is for issues related to the development of GCC. I understand that you are looking at rewriting the C++ parser (why?) but this is just a basic C++ question, not a GCC issue. I don't have a link, but it seems to me that the issue is obvious. The C++ lexer recognizes >> as a single token. So when you write std::vector> the final >> is parsed as a single token, rather than the two separate tokens that the parser expects. Note that this issue is fixed in C++11. Ian
increasing testsuite-errors when optimizing for amdfam10/bdver2
Hi, replacing my AMD Phenom2 with a AMD Piledriver (Bulldozer Version2) was reason enough for me to recompile gcc (and the whole linux-system) with hard optimisation set to bdver2 (as I've done since my first linux on an 68030). But this time an increasing number of errors makes me a little bit nervous and after some additional errors when running the glibc-2.17-testsuite I've refused to use this optimisation as default on my system. The results might be interesting for the gcc-developer-community and I've mailed four results with different set of '--with-arch' and '--with-tune' to gcc-testresu...@gcc.gnu.org from stock gcc-4.8.0. I've set '--build=x86_64-winnix-linux-gnu' just to make it easier to search the archive for this specific results (results include the complete set of relevant libs/tools). Basic flags for every compile/test-run: --build=x86_64-winnix-linux-gnu --enable-languages=c,c++ --enable-shared --prefix=/usr --enable-multilib=no optimization for phenom2 (I've used since I've replaced my Athlon-FX): --with-arch=amdfam10 --with-tune=amdfam10 soft-optimization for bdver2 which is the current configuration I use on my system (no additional errors in glibc-2.17: --with-arch=amdfam10 --with-tune=bdver2 optimization for bdver2: --with-arch=bdver2 --with-tune=bdver2 The number of additional errors is always increasing. Mostly errors in scan-assembler and scan-tree-dump (maybe wrong expections in the tests?) but with arch=bdver2 I see an increasing number of execution-tests failing. Surprisingly (at least for me) the difference is only visible in the gcc-testsuite and doesn't harm other languages. I've done some work to ensure errors are not related to the system-setup and maybe it's of interest what I've learned during this process: gcc.dg/guality/vla-1.c and vla-2.c depends on the gdb-version. Fails with stock gdb-7.5.1 (also tested prerelease gdb-7.5.91) and don't fail with gdb-patches from opensuse (fedora-patches works also). Using tcl8.6.0 as base for expect/dejagnu doesn't currently work, at least not with the gcc-testsuite. Please note that this is not a regression and that gcc-4.7.x gives very similar results. Thank you for listening and all the good work I apreciate since 20 years with all sorts of cpu's and operating-systems gcc supports! best regards winfried
Re: Trying to find a link for information about parsing template parameters and the >> problem
On 01/04/13 17:41, Ian Lance Taylor wrote:
On Mon, Apr 1, 2013 at 8:55 AM, Alec Teal wrote:
I'm still planning to rewrite the c++ parser in GCC, right now I am still
researching, I remember a page that talked about the problems of parsing > in
nested templates, and I cannot find the link!
Searching for it has yielded people asking questions about errors where >>
occurs.
Please provide me with the link.
I'm not sure this kind of message really belongs on the
gcc@gcc.gnu.org mailing list, which is for issues related to the
development of GCC. I understand that you are looking at rewriting
the C++ parser (why?) but this is just a basic C++ question, not a GCC
issue.
An exercise mainly, the goal would be to better facilitate error report
generation, by creating (perhaps with a flag) some sort of AST that may
be dumped or exported. Exporting headers in this form (and importing
later) done with a flag of course. Bringing the parser and symbol table
closer together.
Some things can just be better parsed going from right to left, ; end a
statement and { } form lovely blocks, reading from right to left
shouldn't be too bad at all, nor would perhaps threading complication
(this is just a thought, I know compiling is a task that lends itself to
being done in parallel rather nicely), with this format too you could
perhaps (again with flags) store 'notes' about a function with the hash
of the tokens that make it up, save recompiling an entire file. This
data wouldn't go inside the object file, and these are just some thoughts.
Having such a note file could be useful if any compiler instance can
write to it (if the thing it is notes of is being used) to build a
program-wide callgraph while compiling, I suspect LTO does this already
within the object file though.
If IDEs could make use of this file it'd be even better. I understand
I've gotten quite far from "why the parser" now.
I don't have a link, but it seems to me that the issue is obvious.
The C++ lexer recognizes >> as a single token. So when you write
std::vector>
the final >> is parsed as a single token, rather than the two separate
tokens that the parser expects.
Yes that is (was) the problem, I remember reading a document online, I
cannot recall where that looked at three ways of solving it and
evaluated them, I know of the problem but I want that guy's evaluation!
the article spoke about GCC, I'm sure it was under the gnu domain
gah! I wish I could recall!
Note that this issue is fixed in C++11.
Ian
Alec
Re: Trying to find a link for information about parsing template parameters and the >> problem
On 1 April 2013 20:43, Alec Teal wrote: >> I don't have a link, but it seems to me that the issue is obvious. >> The C++ lexer recognizes >> as a single token. So when you write >> std::vector> >> the final >> is parsed as a single token, rather than the two separate >> tokens that the parser expects. > > Yes that is (was) the problem, I remember reading a document online, I cannot > recall where that looked at three ways of solving it and evaluated them, I > know of the problem but I want that guy's evaluation! the article spoke about > GCC, I'm sure it was under the gnu domain gah! I wish I could recall! Probably http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
Re: Trying to find a link for information about parsing template parameters and the >> problem
On 01/04/13 21:08, Jonathan Wakely wrote: On 1 April 2013 20:43, Alec Teal wrote: [snip] Yes that is (was) the problem, I remember reading a document online, I cannot recall where that looked at three ways of solving it and evaluated them, I know of the problem but I want that guy's evaluation! the article spoke about GCC, I'm sure it was under the gnu domain gah! I wish I could recall! Probably http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html It is! Thanks once again Jonathan. Alec
Re: [Patch, testsuite] Add missing -gdwarf-2 flag in debug/dwarf2 testcase
On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote: I couldn't find a way to ask gcc to just generate DWARF (default version) either. How should this be fixed? Maybe we could use -gdwarf for that now, since we stopped using it for DWARF 1 in GCC 3.4. Jason
Re: [Patch, testsuite] Add missing -gdwarf-2 flag in debug/dwarf2 testcase
On Apr 1, 2013, at 6:43 PM, Jason Merrill wrote: > On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote: >> I couldn't find a way to ask gcc to just generate DWARF (default >> version) either. How should this be fixed? > > Maybe we could use -gdwarf for that now, since we stopped using it for DWARF > 1 in GCC 3.4. I like that.
