Typo: gcc-5/changes.html
In gcc-5/changes.html the section about __has_include and __has_include_next says: The header search paths for __has_include_next and __has_include_next are equivalent to those of the standard directive #include and the extension #include_next respectively. I think the first __has_include_next should be an __has_include. /MF
Re: Remove unused debugging arg from last change
On Tue, Oct 23, 2012 at 03:28:37PM -0600, Jeff Law wrote:
Committed as obvious.
* tree-ssa-threadedge.c (cond_arg_set_in_bb): Remove unused
debugging argument.
Could you please remove the third argument in the calls to cond_arg_set_in_bb
as well?
/MF
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c (revision 192745)
+++ tree-ssa-threadedge.c (working copy)
@@ -580,7 +580,7 @@
in e-dest. */
static bool
-cond_arg_set_in_bb (edge e, basic_block bb, int n)
+cond_arg_set_in_bb (edge e, basic_block bb)
{
ssa_op_iter iter;
use_operand_p use_p;
Re: add typedef printers to libstdc++
On Fri, 2012-09-21 at 14:59 -0600, Tom Tromey wrote: This patch adds some typedef printers to libstdc++. This relies on a gdb patch that hasn't yet gone in (pending on the list). If the gdb patch changes, I'll change these printers as well. The basic idea is that you can now have gdb substitute a name of your choice when printing a type's name. This lets a library pretend that some typedefs are canonical. This includes a fairly comprehensive test case for the new type printers. I have not tested it, but when looking at the test case and also on the code I couldn't help but ask myself how it handles other derivations. How does it display the types of the variables us, s and ss in the following code: --- #include string typedef std::basic_stringunsigned char ustring; ustring us; std::string s; std::basic_stringsigned char ss; --- I would expect it to say std::basic_stringunsigned char,..., std::string and std::basic_stringsigned char,..., but I thought a test case here couldn't hurt? /MF
Re: [bootstrap] Tentative fix for PR 54281
On Thu, Aug 16, 2012 at 07:55:51AM -0400, Diego Novillo wrote: Richi, this implements your idea for fixing PR 54281. I don't have an old enough compiler. Could you please test it in your system? I debated whether to remove the GENERATOR_FILE predicate from the inclusion (some files include gmp.h unconditionally). I think it could be removed, but only a minority of files build with GENERATOR_FILE set, so it didn't seem harmful. OK if tests pass? This patch breaks building with gmp, cloog and isl in subdirectories of the source tree. echo timestamp s-options gawk -f ../../trunk/gcc/opt-functions.awk -f ../../trunk/gcc/opt-read.awk \ -f ../../trunk/gcc/opth-gen.awk \ optionlist tmp-options.h /bin/sh ../../trunk/gcc/../move-if-change tmp-options.h options.h echo timestamp s-options-h TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h DEFINES= \ /bin/sh ../../trunk/gcc/mkconfig.sh bconfig.h g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/magfr/src/gcc/build/./gmp -I/home/magfr/src/gcc/trunk/gmp -I/home/magfr/src/gcc/build/./mpfr -I/home/magfr/src/gcc/trunk/mpfr -I/home/magfr/src/gcc/trunk/mpc/src -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_INT_GMP -I/home/magfr/src/gcc/build/./cloog/include -I/home/magfr/src/gcc/trunk/cloog/include -I../trunk/cloog/include -I/home/magfr/src/gcc/build/./isl/include -I/home/magfr/src/gcc/trunk/isl/include \ -o build/genconstants.o ../../trunk/gcc/genconstants.c In file included from /usr/include/sys/resource.h:25:0, from /usr/include/sys/wait.h:32, from ../../trunk/gcc/system.h:351, from ../../trunk/gcc/genconstants.c:29: /usr/include/bits/resource.h:133:18: error: declaration does not declare anything [-fpermissive] In file included from ../../trunk/gcc/genconstants.c:29:0: ../../trunk/gcc/system.h:443:23: error: declaration of C function `void* sbrk(int)' conflicts with In file included from ../../trunk/gcc/system.h:253:0, from ../../trunk/gcc/genconstants.c:29: /usr/include/unistd.h:1067:14: error: previous declaration `void* sbrk(intptr_t)' here In file included from ../../trunk/gcc/genconstants.c:29:0: ../../trunk/gcc/system.h:447:48: error: new declaration `char* strstr(const char*, const char*)' In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cstring:44:0, from ../../trunk/gcc/system.h:207, from ../../trunk/gcc/genconstants.c:29: /usr/include/string.h:323:22: error: ambiguates old declaration `const char* strstr(const char*, const char*)' In file included from ../../trunk/gcc/genconstants.c:29:0: ../../trunk/gcc/system.h:499:34: error: declaration of C function `const char* strsignal(int)' conflicts with In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cstring:44:0, from ../../trunk/gcc/system.h:207, from ../../trunk/gcc/genconstants.c:29: /usr/include/string.h:566:14: error: previous declaration `char* strsignal(int)' here In file included from ../../trunk/gcc/system.h:639:0, from ../../trunk/gcc/genconstants.c:29: ../../trunk/gcc/../include/libiberty.h:110:36: error: new declaration `char* basename(const char*)' In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cstring:44:0, from ../../trunk/gcc/system.h:207, from ../../trunk/gcc/genconstants.c:29: /usr/include/string.h:603:28: error: ambiguates old declaration `const char* basename(const char*)' make[3]: *** [build/genconstants.o] Error 1 make[3]: Leaving directory `/home/magfr/src/gcc/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/magfr/src/gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/magfr/src/gcc/build' make: *** [all] Error 2 The problem seems to be that during configure time the test scripts include system.h, but it fails to add the gmp include directory to the compiler flags so the checks for sbrk, strstr and so on fails with configure:10294: checking whether sbrk is declared configure:10317: gcc -c -g -I../../trunk/gcc -I../../trunk/gcc/../include conftest.c 5 In file included from conftest.c:125:0: ../../trunk/gcc/system.h:1041:17: fatal error: gmp.h: No such file or directory compilation terminated. configure:10317: $? = 1 Reverting this patch makes the compiler build. /MF
Re: [PATCH] Move Graphite from using PPL over to ISL
Hello. Ever since the ISL patch went in my builds have failed. I am building with local copies of all the libraries, so I have added gmp, mpfr, mpc, isl and cloog from ftp://gcc.gnu.org/pub/gcc/infrastructure to my source directory. The command sequence I use is svn co svn://gcc.gnu.org/svn/gcc/trunk cd trunk ./contrib/download_prerequisites wget ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-0.17.0.tar.gz ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.10.tar.bz2 tar xjf isl-0.10.tar.bz2 tar xzf cloog-0.17.0.tar.gz ln -s cloog-0.17.0 cloog ln -s isl-0.10 isl cd .. mkdir build cd build ../trunk/configure make V=1 and the error message I get is make[5]: Entering directory `/home/maf/src/gcc/build/isl' /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../trunk/isl -I../../trunk/isl/include -Iinclude/ -I. -I../../trunk/isl -I../../trunk/isl/include -Iinclude/ -g -fkeep-inline-functions -MT libisl_la-isl_lp_no_piplib.lo -MD -MP -MF .deps/libisl_la-isl_lp_no_piplib.Tpo -c -o libisl_la-isl_lp_no_piplib.lo `test -f 'isl_lp_no_piplib.c' || echo '../../trunk/isl/'`isl_lp_no_piplib.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../trunk/isl -I../../trunk/isl/include -Iinclude/ -I. -I../../trunk/isl -I../../trunk/isl/include -Iinclude/ -g -fkeep-inline-functions -MT libisl_la-isl_lp_no_piplib.lo -MD -MP -MF .deps/libisl_la-isl_lp_no_piplib.Tpo -c ../../trunk/isl/isl_lp_no_piplib.c -o libisl_la-isl_lp_no_piplib.o In file included from ../../trunk/isl/include/isl/lp.h:13:0, from ../../trunk/isl/isl_lp_piplib.h:13, from ../../trunk/isl/isl_lp_no_piplib.c:10: ../../trunk/isl/include/isl/int.h:15:17: fatal error: gmp.h: No such file or directory compilation terminated. make[5]: *** [libisl_la-isl_lp_no_piplib.lo] Error 1 make[5]: Leaving directory `/home/maf/src/gcc/build/isl' Making all in doc make[5]: Entering directory `/home/maf/src/gcc/build/isl/doc' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/maf/src/gcc/build/isl/doc' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/maf/src/gcc/build/isl' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/maf/src/gcc/build/isl' make[2]: *** [all-stage1-isl] Error 2 make[2]: Leaving directory `/home/maf/src/gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/maf/src/gcc/build' make: *** [all] Error 2 but 'ls gmp/gmp.h' shows that the file is there. Please note that my machine lack the gmp-devel package, so there is no /usr/include/gmp.h. Adding that package makes the build succeed, but that sounds ridiculous as there is a local copy. /MF
Re: [wwwdocs] Update coding conventions for C++
On Mon, 2012-06-25 at 15:17 -0700, Lawrence Crowl wrote: On 6/25/12, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 25 Jun 2012, Diego Novillo wrote: [ Added doc maintainers in CC ] I have added a bit more in the rationale, reached through the link at the end of that section. +p +Indent protection labels by one space. +/p + +p +Indent class members by two spaces. Do all the listed indentation rules correspond to what a TAB will do by default when editing C++ code in GNU Emacs? If not, we have conflicting notions of GNU C++ indentation conventions. I have no idea. I don't use emacs. The two-space rule for members comes from the wiki. The one-space rule for protection labels is common practice. If folks want something else, changes are fine with me. Two spaces for members is common practice with GNU, and it seems to be used for libstdc++. One space for protection labels is not something I have heard of before and libstdc++ uses no indentation for them. A freshly started emacs also doesn't indent access labels. I do think there is some value in using the same coding style for libstdc++ and the compiler. /MF
Re: PING: [C++-11 PATCH] Trailing comma in enum
On Sat, 2011-10-29 at 20:48 +0300, Ville Voutilainen wrote:
Could someone please review this?
+ if (cxx_dialect cxx0x !in_system_header)
+ pedwarn (input_location, OPT_pedantic,
+ comma at end of enumerator list);
Why not use maybe_warn_cpp0x there?
maybe_warn_cpp0x seems to handle cases were C++11 extensions are used
but in this case a GNU extension is adopted by the standard so I wanted
to make a minimal change.
Attached is a variation where maybe_warn_cpp0x is used.
Please note how my new pedwarn breaks the pattern in maybe_warn_cpp0x.
One could of course imagine changing the message to something like
comma at end of enumerator list is not a warning \
with -std=c++0x or -std=gnu++0x
but it still stands out as different in that function so I do not
know...
/MF
Index: gcc/cp/error.c
===
--- gcc/cp/error.c (revision 180672)
+++ gcc/cp/error.c (working copy)
@@ -3255,6 +3255,10 @@
user-defined literals
only available with -std=c++0x or -std=gnu++0x);
break;
+ case CPP0X_ENUM_TRAILING_COMMA:
+ pedwarn (input_location, OPT_pedantic,
+ comma at end of enumerator list);
+ break;
default:
gcc_unreachable ();
}
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 180672)
+++ gcc/cp/parser.c (working copy)
@@ -14058,6 +14058,7 @@
enum-specifier:
enum-head { enumerator-list [opt] }
+ enum-head { enumerator-list , } [C++11]
enum-head:
enum-key identifier [opt] enum-base [opt]
@@ -14077,6 +14078,8 @@
GNU Extensions:
enum-key attributes[opt] identifier [opt] enum-base [opt]
{ enumerator-list [opt] }attributes[opt]
+ enum-key attributes[opt] identifier [opt] enum-base [opt]
+ { enumerator-list , }attributes[opt] [C++11]
Returns an ENUM_TYPE representing the enumeration, or NULL_TREE
if the token stream isn't an enum-specifier after all. */
@@ -14416,8 +14419,7 @@
/* If the next token is a `}', there is a trailing comma. */
if (cp_lexer_next_token_is (parser-lexer, CPP_CLOSE_BRACE))
{
- if (!in_system_header)
- pedwarn (input_location, OPT_pedantic, comma at end of enumerator list);
+ maybe_warn_cpp0x(CPP0X_ENUM_TRAILING_COMMA);
break;
}
}
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h (revision 180672)
+++ gcc/cp/cp-tree.h (working copy)
@@ -402,7 +402,9 @@
/* non-static data member initializers */
CPP0X_NSDMI,
/* user defined literals */
- CPP0X_USER_DEFINED_LITERALS
+ CPP0X_USER_DEFINED_LITERALS,
+ /* trailing comma in enumerations */
+ CPP0X_ENUM_TRAILING_COMMA
} cpp0x_warn_str;
/* The various kinds of operation used by composite_pointer_type. */
Index: gcc/testsuite/g++.dg/cpp0x/enum21a.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum21a.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum21a.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options -pedantic-errors -std=c++98 }
+
+enum x { y, }; // { dg-error comma at end of enumerator list }
Index: gcc/testsuite/g++.dg/cpp0x/enum21b.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum21b.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum21b.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options -pedantic-errors -std=c++0x }
+
+enum x { y, };
PING: [C++-11 PATCH] Trailing comma in enum
Could someone please review this?
On Sun, 2011-10-09 at 16:27 +0200, Magnus Fromreide wrote:
Hi.
As I understand it C++-11 allows trailing commas in enum definitions.
Thus I think the following little patch should be included.
/MF
2011-10-09 Magnus Fromreide ma...@lysator.liu.se
* gcc/cp/parser.c (cp_parser_enumerator_list): Do not warn about
trailing commas in C++11 mode.
* gcc/testsuite/g++.dg/cpp0x/enum21a.C: Test that enum x { y, } do
generate a pedwarning in c++98-mode.
* gcc/testsuite/g++.dg/cpp0x/enum21b.C: Test that enum x { y, }
don't generate a pedwarning in c++11-mode.
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 180624)
+++ gcc/cp/parser.c (working copy)
@@ -14058,6 +14058,7 @@
enum-specifier:
enum-head { enumerator-list [opt] }
+ enum-head { enumerator-list , } [C++11]
enum-head:
enum-key identifier [opt] enum-base [opt]
@@ -14077,6 +14078,8 @@
GNU Extensions:
enum-key attributes[opt] identifier [opt] enum-base [opt]
{ enumerator-list [opt] }attributes[opt]
+ enum-key attributes[opt] identifier [opt] enum-base [opt]
+ { enumerator-list , }attributes[opt] [C++11]
Returns an ENUM_TYPE representing the enumeration, or NULL_TREE
if the token stream isn't an enum-specifier after all. */
@@ -14416,8 +14419,9 @@
/* If the next token is a `}', there is a trailing comma. */
if (cp_lexer_next_token_is (parser-lexer, CPP_CLOSE_BRACE))
{
- if (!in_system_header)
- pedwarn (input_location, OPT_pedantic, comma at end of enumerator list);
+ if (cxx_dialect cxx0x !in_system_header)
+ pedwarn (input_location, OPT_pedantic,
+ comma at end of enumerator list);
break;
}
}
Index: gcc/testsuite/g++.dg/cpp0x/enum21a.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum21a.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum21a.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options -pedantic-errors -std=c++98 }
+
+enum x { y, }; // { dg-error comma at end of enumerator list }
Index: gcc/testsuite/g++.dg/cpp0x/enum21b.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum21b.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum21b.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options -pedantic-errors -std=c++0x }
+
+enum x { y, };
[C++ Patch] Trailing comma in enum
Hi.
As I understand it C++11 allows trailing commas in enum definitions.
Thus I think the following little patch should be included.
On a side note I have to say that the effects of pedwarn_cxx98 are
unexpected, especially in light of the comment above the function body.
/MF
2011-10-09 Magnus Fromreide ma...@lysator.liu.se
* gcc/cp/parser.c (cp_parser_enumerator_list): Do not warn about
trailing commas in C++0x mode.
* gcc/testsuite/g++.dg/cpp0x/enum21a.C: Test that enum x { y, } do
generate a pedwarning in c++98-mode.
* gcc/testsuite/g++.dg/cpp0x/enum21b.C: Test that enum x { y, }
don't generate a pedwarning in c++0x-mode.
Index: gcc/testsuite/g++.dg/cpp0x/enum21a.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum21a.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum21a.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options -pedantic }
+
+enum x { y, }; // { dg-warning comma at end of enumerator list }
Index: gcc/testsuite/g++.dg/cpp0x/enum21b.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum21b.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum21b.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options -pedantic -std=c++0x }
+
+enum x { y, };
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 179711)
+++ gcc/cp/parser.c (working copy)
@@ -13444,6 +13444,7 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
enum-specifier:
enum-head { enumerator-list [opt] }
+ enum-head { enumerator-list , } [C++0x]
enum-head:
enum-key identifier [opt] enum-base [opt]
@@ -13463,6 +13464,8 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
GNU Extensions:
enum-key attributes[opt] identifier [opt] enum-base [opt]
{ enumerator-list [opt] }attributes[opt]
+ enum-key attributes[opt] identifier [opt] enum-base [opt]
+ { enumerator-list, }attributes[opt] [C++0x]
Returns an ENUM_TYPE representing the enumeration, or NULL_TREE
if the token stream isn't an enum-specifier after all. */
@@ -13802,8 +13805,9 @@ cp_parser_enumerator_list (cp_parser* parser, tree
/* If the next token is a `}', there is a trailing comma. */
if (cp_lexer_next_token_is (parser-lexer, CPP_CLOSE_BRACE))
{
- if (!in_system_header)
- pedwarn (input_location, OPT_pedantic, comma at end of enumerator list);
+ if (cxx_dialect cxx0x !in_system_header)
+ pedwarn (input_location, OPT_pedantic,
+ comma at end of enumerator list);
break;
}
}
Re: [v3] Re-implement is_constructible, add is_default_constructible, is_destructible, fix PR 48526
On Thu, 2011-04-14 at 00:48 +0200, Paolo Carlini wrote: Hi! over the last 2 days or so, Daniel Krugler - having filed in due course his Copyright Assignment - finally kindly contributed to the project shiny new std::is_constructible, std::is_default_constructible and std::is_destructible. Being his first contribution, I helped integrating the work in our existing type_traits infrastructure. As you can see, I also took the occasion to use the new logical helper traits elsewhere, add a few more tweaks (remove a rather redundant macro, at this point), and also add tests in areas where the testsuite was weak (particularly because for some time we could assume shared code was at least exercised by the tr1/ testsuite). This is just a nit, but why do you remove the /// is_function comments? /MF
Re: Implement stack arrays even for unknown sizes
On Sat, 2011-04-09 at 09:21 +0100, N.M. Maclaren wrote: On Apr 8 2011, Michael Matz wrote: It adds a new option -fstack-arrays which makes the frontend put all local arrays on stack memory. ... Excellent! I haven't rechecked performance now, but four months ago this was the result for the fortran benchmarks in cpu2006: There is actually a much better approach, which was done in Algol 68 and seems now to be done only in Ada. As far as the compiler implementation goes, it is a trivial variation on what you have done, but there is a little more work in the run-time system. That is to use primary and secondary stacks. ... How does your secondary stack interact with threads? Do it force the use of more memory per thread? /MF
