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;
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
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
* 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, };
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, };
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: 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 typedef std::basic_string ustring; ustring us; std::string s; std::basic_string ss; --- I would expect it to say std::basic_string, std::string and std::basic_string, but I thought a test case here couldn't hurt? /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 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. > > > > > + > > > > +Indent protection labels by one space. > > > > + > > > > + > > > > + > > > > +Indent class members by two spaces. > > > > Do all the listed indentation rules correspond to what a > > 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: [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: [PATCH] Move Graphite from using PPL over to ISL
On Thu, Jul 05, 2012 at 11:51:19AM +0200, Richard Guenther wrote: > On Thu, 5 Jul 2012, Richard Guenther wrote: > > > On Thu, 5 Jul 2012, Richard Guenther wrote: > > > > > On Thu, 5 Jul 2012, Tristan Gingold wrote: > > > > > > > > > > > On Jul 4, 2012, at 8:31 PM, Magnus Fromreide wrote: > > > > > > > > > Hello. > > > > > > > > > > Ever since the ISL patch went in my builds have failed. > > > > > > > > Which ISL patch ? > > > > > > > > > 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. > > > > > > > > I am not familiar with this build (I usually build gmp/mpfr/... once > > > > and install them). > > > > But it looks like isl doesn't see the gmp includes. But according to > > > > $(srcdir)/Makefile.in, > > > > gmp is configured with --with-gmp-include. Was isl correctly > > > > configured in your case ? > > > > > > I have not tested builds with gmp/mpfr in the source tree but have > > > copied the logic from the old ppl/cloog configury. Can you try > > > to replace $$r/$(HOST_SUBDIR)/gmp with $$s/gmp in Makefile.def? > > > The issue is we can't specify both source and build dirs here > > > (so the underlying issue is packages expect installed gmp but we don't > > > actually install it - they are not expecting to be used as-is in > > > their build directory). > > > > Looking at isl/cloog configure in detail it seems that the following might > > work (tested with all reqs in tree only yet). Hopefully it autodetects > > the case where the build dir does not exist and uses the system library > > instead then (of course alternate gmp install dirs are still not properly > > passed down I guess). > > Does not work with out-of-tree gmp. Any suggestion on how to > conditionalize Makefile.def extra_configure_flags on the presence > of a host_module? First, sorry for not having been able to get back to you earlier. I agree. That AX_SUBMODULE macro is somewhat annoying, it seems the main use of it is so that ISL can get hold of the srcdir for an uninstalled build when it is used in the context of gmp. Now, if I build with --with-gmp-builddir=$$r/$(HOST_SUBDIR)/gmp then it works in my setup. If we suppose that gmp is installed with headers under /some/place/include and libs under /another/place/lib then one could use --with-gmp-prefix=/some/place --with-gmp-exec-prefix=/another/place except that there is a bug in the ISL configure script so it uses gmp-prefix for both include and lib, and this also requires that the include and lib parts of the paths are there. Would it be possible to actually install the libraries somewhere under build and then link against them? /MF
[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
* 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: [Patch] tree-parloops.c (eliminate_local_variables): Add braces to suppress warnings
On Fri, 2012-04-13 at 16:50 +0200, Bernd Schmidt wrote: > On 04/13/2012 04:44 PM, Jakub Jelinek wrote: > > On Fri, Apr 13, 2012 at 04:33:17PM +0200, Bernd Schmidt wrote: > >> On 04/13/2012 04:20 PM, Mike Stump wrote: > >>> On Apr 13, 2012, at 5:30 AM, NightStrike wrote: > > no warning from trunk. Which GCC version emits this warning? > >>> > Looks like cygwin gcc 3.4.4 > >>> > >>> 3.4.4 is a little old now.. We'd encourage an upgrade to a fine new > >>> compiler... :-) > >> > >> The thing is, the else really is ambiguous, so it looks like we have a > >> warning regression. > > > > To the compiler? There is for in between, no need to put extra braces IMHO. > > I believe it has been intentionally fixed for 4.0, but my bisect tree only > > goes back to r9. > > Well, to the compiler even > if () > if () > x > else > y > > has an unambiguous meaning. The problem is that a human might be > confused, for example due to bad indentation. For me this warning is almost always a false positive since I am unable to turn it of selectively. I am programming in C++. My main use of if () ; else y is to get a temporary scope that doesn't have any braces, e.g. in this macro #define DEBUG if (!enable_debugging) ; else debug_object() where debug_object is an instance of std::ostream. I then use it like DEBUG << "fancy message goes here"; Now, writing if (condition) DEBUG << "ooops, condition is true"; is not that far-fetched and obviously triggers the warning but I have a hard time seeing how that is confusing to a casual reader of the code. (In order to avoid this warning I am currently writing the above code as #define DEBUG switch (!enable_debugging) case false: debug_object() but that makes the define harder to understand and so the net result of the warning is to reduce the clarity of the code) /MF
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 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
