Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/13/2012 9:15 PM, Chiheng Xu wrote:


So, I can say, most of the GCC source code is in large files.

And this also hold for language front-ends.


I see nothing inherently desirable about having all small files.
For example, in GNAT, yes, some files are large, sem_ch3 (semantic
analysis for chapter 3 stuff which includes all of type handling)
is large (over 20,000 lines 750KB, but nothing would be gained
(and something would be lost) by trying to split this file up.

As long as all your tools can handle large files nicely, and
as long as the internal organization of the large file is
clean and clear, I see no problem.

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/13/2012 9:34 PM, Chiheng Xu wrote:

On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
  wrote:


Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++ compiler? ...



Probably, if you can refrain from using some "advance" C++
features(namespace, template, etc.),  you will not have such
annoyances.


To me namespaces are fundamental in terms of the advantages that
moving to C++ can give in a large project, I would never regard
them as some "advanced" feature to be avoided. If namespaces
cause trouble for the debugger, that's surprising and problematic!

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Sat, Apr 14, 2012 at 5:09 PM, Robert Dewar  wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>>   wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably, if you can refrain from using some "advance" C++
>> features(namespace, template, etc.),  you will not have such
>> annoyances.
>
>
> To me namespaces are fundamental in terms of the advantages that
> moving to C++ can give in a large project, I would never regard
> them as some "advanced" feature to be avoided. If namespaces
> cause trouble for the debugger, that's surprising and problematic!
>>
>>
>

If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.

But personally, when I write C++ code, I never use namespace.  I
always prefix my class name(and corresponding source file names) with
proper module name, and put the all source files of a module in its
dedicated sub-directory .  This make class name globally unique
throughout the project, and facilitate further re-factoring(searching
and replacing).

When using namespace,  people can and tend to use the same name in
different namespaces,  this seems like a advantage, but I see it as a
disadvantage. If you want to change a name in one namespace to some
other more accurate/proper name,  you use some search tools to search
all the references of the name, you will find that the name is
probably also used in other namespaces, so you just can't use "replace
all" command to replace all references with the new name, you must
manually replace them one by one. Is this what you want ?.

And, frankly speaking, I don't like "::".   For example A::B, sometime
it means name B in namespace A, sometime it means member B of class A.
This depend whether A is class or namespace. But when you first read
code, this information is unclear, you must guess, until you have read
enough code to known what A is.


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar  wrote:
> On 4/13/2012 9:15 PM, Chiheng Xu wrote:
>
>> So, I can say, most of the GCC source code is in large files.
>>
>> And this also hold for language front-ends.
>
>
> I see nothing inherently desirable about having all small files.
> For example, in GNAT, yes, some files are large, sem_ch3 (semantic
> analysis for chapter 3 stuff which includes all of type handling)
> is large (over 20,000 lines 750KB, but nothing would be gained
> (and something would be lost) by trying to split this file up.
>
> As long as all your tools can handle large files nicely, and
> as long as the internal organization of the large file is
> clean and clear, I see no problem.
>>
>>
>

Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the functions in large file are sub-routines(directly
or indirectly) of the entry points. The functions can be divided into
several groups or layers, each group or layer can form a conceptual
sub-module. I often see GCC developer divide functions in large file
into sub-modules by prefix them with sub-module specific prefix and
group them together.  This is good,  but not enough. If the functions
in sub-modules are put in separate files,  then the code will be more
manageable than not doing so. This is because the
interfaces/boundaries between sub-modules are more clear, and the code
have higher cohesion and lower coupling.


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Sat, Apr 14, 2012 at 4:09 AM, Robert Dewar  wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>>   wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably, if you can refrain from using some "advance" C++
>> features(namespace, template, etc.),  you will not have such
>> annoyances.
>
>
> To me namespaces are fundamental in terms of the advantages that
> moving to C++ can give in a large project, I would never regard
> them as some "advanced" feature to be avoided. If namespaces
> cause trouble for the debugger, that's surprising and problematic!

Indeed, the notion that 'namspace' is "advance" is troublesome.
Similarly I would find any notion that simple uses  and definitions
of templates (functions, datatypes) "advanced" a bit specious.

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/14/2012 6:38 AM, Chiheng Xu wrote:


Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the functions in large file are sub-routines(directly
or indirectly) of the entry points. The functions can be divided into
several groups or layers, each group or layer can form a conceptual
sub-module. I often see GCC developer divide functions in large file
into sub-modules by prefix them with sub-module specific prefix and
group them together.  This is good,  but not enough. If the functions
in sub-modules are put in separate files,  then the code will be more
manageable than not doing so. This is because the
interfaces/boundaries between sub-modules are more clear, and the code
have higher cohesion and lower coupling.


I find the claim unconvincing in practice, it is possible to have code
in separate files with unclear interfaces and boundaries, and code in
single files with perfectly clear interfaces and boundaries. You can
claim without evidence that there is a causal relation here but that
is simply not the case in my experience.

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/14/2012 6:39 AM, Gabriel Dos Reis wrote:


Indeed, the notion that 'namspace' is "advance" is troublesome.
Similarly I would find any notion that simple uses  and definitions
of templates (functions, datatypes) "advanced" a bit specious.


Indeed! In the case of templates there is a real issue, in that
we all know that misuse of templates can get completely out of
hand, but to suggest banning all templates is not a supportable
notion.

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/14/2012 6:02 AM, Chiheng Xu wrote:


If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.

But personally, when I write C++ code, I never use namespace.  I
always prefix my class name(and corresponding source file names) with
proper module name, and put the all source files of a module in its
dedicated sub-directory .  This make class name globally unique
throughout the project, and facilitate further re-factoring(searching
and replacing).


I find that rather a horrible substitute for proper use of namespaces.
I know it is common, partly because that's what you have to do in C,
and partly because namespac3es were added late


When using namespace,  people can and tend to use the same name in
different namespaces,  this seems like a advantage, but I see it as a
disadvantage.


I think that is a seriously misguided position. There is a good reason
for adding namespaces (Ada has always had this kind of capability in
the form of packages, and the package concept in Ada is, to Ada
programmers, one of its most powerful features). Since you never use
namespaces, it is not surprising that you do not appreicate their
importance.

To me, the ability to make extensive use of namespaces is one of
the strong arguments for switching to C++


If you want to change a name in one namespace to some
other more accurate/proper name,  you use some search tools to search
all the references of the name, you will find that the name is
probably also used in other namespaces, so you just can't use "replace
all" command to replace all references with the new name, you must
manually replace them one by one. Is this what you want ?.


You use proper tools that do the replacement just of references to
the entity whose name you want to change. It is often the case that
people avoid use of features because of a lack of proper tools, but
certainly there are tools that can do this kind of intelligent
replacement (GPS from AdaCore is one such example, but we certainly
wouldn't suggest it was unique in this respect!)

Re: Switching to C++ by default in 4.8

[Jonathan Wakely]

On 14 April 2012 11:02, Chiheng Xu wrote:
>
> If debugger fully support namespace, that will be nice. I just say,
> in case debugger have trouble with namespace, you can avoid it.

So it's completely unfounded speculation then.

> But personally, when I write C++ code, I never use namespace.  I
> always prefix my class name(and corresponding source file names) with
> proper module name, and put the all source files of a module in its
> dedicated sub-directory .  This make class name globally unique
> throughout the project, and facilitate further re-factoring(searching
> and replacing).

Find'n'replace is not refactoring.

Problems building 4.8 snapshot with CygWin

[Nicolai Josuttis]

Hi,

I am currently trying to build
 gcc-4.8-20120401.tar.bz2
on my Windows 7 Pro system using CygWin.
I am using the following configuration settings:
 configure \
 --enable-languages=c++ \
 --disable-bootstrap \
 --prefix=/cygdrive/p/gcc$VERSION \
 --program-suffix=$VERSION \
 --with-gxx-include-dir=/cygdrive/p/gcc$VERSION-include \
 --disable-lto
and build with
 gmp-4.3.2
 mpc-0.8.2
 mpfr-2.4.2

The first problem was that
 build/gcc/gengtype-lex.c
was created with DOS-Newlines (CR-LF),
which makes the following compiling fail:
make[2]: Entering directory `/cygdrive/p/gcc480snap-install/build/gcc'
gcc -c-g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute 
-Wold-style-definition -fno-common -Wno-error -DHAVE_CONFIG_H 
-DGENERATOR_FILE -I. -Ibuild -I../../src/gcc-4.8-20120401/gcc 
-I../../src/gcc-4.8-20120401/gcc/build 
-I../../src/gcc-4.8-20120401/gcc/../include 
-I../../src/gcc-4.8-20120401/gcc/../libcpp/include 
-I/cygdrive/p/gcc480snap-install/build/./gmp 
-I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/gmp 
-I/cygdrive/p/gcc480snap-install/build/./mpfr 
-I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpfr 
-I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpc/src 
-I../../src/gcc-4.8-20120401/gcc/../libdecnumber 
-I../../src/gcc-4.8-20120401/gcc/../libdecnumber/bid -I../libdecnumber \

-o build/gengtype-lex.o gengtype-lex.c
After SED-ing CR-LF to LF in that file the compilation continues.

But now another problem occurs:
Making all in libsupc++
make[4]: Entering directory 
`/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/libsupc++'
/bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile 
/cygdrive/p/gcc480snap-install/build/./gcc/xgcc -shared-libgcc 
-B/cygdrive/p/gcc480snap-install/build/./gcc -nostdinc++ 
-L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src 
-L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src/.libs 
-B/cygdrive/p/gcc48/i686-pc-cygwin/bin/ 
-B/cygdrive/p/gcc48/i686-pc-cygwin/lib/ -isystem 
/cygdrive/p/gcc48/i686-pc-cygwin/include -isystem 
/cygdrive/p/gcc48/i686-pc-cygwin/sys-include 
-I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/libstdc++-v3/../libgcc 

-I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin 
-I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include 
-I/cygdrive/p/gcc480snap-install/
src/gcc-4.8-20120401/libstdc++-v3/libsupc++  -prefer-pic-Wall 
-Wextra -Wwrite-strings -Wcast-qual -Wabi 
-fdiagnostics-show-location=once-ffunction-sections -fdata-sections 
 -frandom-seed=eh_personality.lo -g -O2 -c -o eh_personality.lo 
../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc
libtool: compile:  /cygdrive/p/gcc480snap-install/build/./gcc/xgcc 
-shared-libgcc -B/cygdrive/p/gcc480snap-install/build/./gcc -nostdinc++ 
-L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src 
-L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src/.libs 
-B/cygdrive/p/gcc48/i686-pc-cygwin/bin/ 
-B/cygdrive/p/gcc48/i686-pc-cygwin/lib/ -isystem 
/cygdrive/p/gcc48/i686-pc-cygwin/include -isystem 
/cygdrive/p/gcc48/i686-pc-cygwin/sys-include 
-I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/libstdc++-v3/../libgcc 
-I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin 
-I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include 
-I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/libstdc++-v3/libsupc++ 
-Wall -Wex
tra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once 
-ffunction-sections -fdata-sections -frandom-seed=eh_personality.lo -g 
-O2 -c 
../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc -o 
eh_personality.o
../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc: 
In function '_Unwind_Reason_Code __cxxabiv1::__gxx_personality_sj0(int, 
_Unwind_Action, _Unwind_Exception_Class, _Unwind_Exception*, 
_Unwind_Context*)':
../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc:711:1: 
error: verify_flow_info: Block 93 lacks loop_father
../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc:711:1: 
error: verify_flow_info: Block 94 lacks loop_father
../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc:711:1: 
internal compiler error: verify_flow_info failed

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:587: recipe for target `eh_personality.lo' failed
make[4]: *** [eh_personality.lo] Error 1
make[4]: Leaving directory 
`/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/libsupc++'

Makefile:471: recipe for target `all-recursive' failed

Any idea what to do here?

Should I submit a bug report for the first gengtype-lex.c problem?

Is the 

Re: Problems building 4.8 snapshot with CygWin

[Kai Tietz]

2012/4/14 Nicolai Josuttis:
> Hi,
>
> I am currently trying to build
>  gcc-4.8-20120401.tar.bz2
> on my Windows 7 Pro system using CygWin.
> I am using the following configuration settings:
>  configure \
>  --enable-languages=c++ \
>  --disable-bootstrap \
>  --prefix=/cygdrive/p/gcc$VERSION \
>  --program-suffix=$VERSION \
>  --with-gxx-include-dir=/cygdrive/p/gcc$VERSION-include \
>  --disable-lto
> and build with
>  gmp-4.3.2
>  mpc-0.8.2
>  mpfr-2.4.2
>
> The first problem was that
>  build/gcc/gengtype-lex.c
> was created with DOS-Newlines (CR-LF),
> which makes the following compiling fail:
> make[2]: Entering directory `/cygdrive/p/gcc480snap-install/build/gcc'
> gcc -c    -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
> -Wold-style-definition -fno-common -Wno-error -DHAVE_CONFIG_H
> -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc-4.8-20120401/gcc
> -I../../src/gcc-4.8-20120401/gcc/build
> -I../../src/gcc-4.8-20120401/gcc/../include
> -I../../src/gcc-4.8-20120401/gcc/../libcpp/include
> -I/cygdrive/p/gcc480snap-install/build/./gmp
> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/gmp
> -I/cygdrive/p/gcc480snap-install/build/./mpfr
> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpfr
> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpc/src
> -I../../src/gcc-4.8-20120401/gcc/../libdecnumber
> -I../../src/gcc-4.8-20120401/gcc/../libdecnumber/bid -I../libdecnumber     \
>        -o build/gengtype-lex.o gengtype-lex.c
> After SED-ing CR-LF to LF in that file the compilation continues.
>
> But now another problem occurs:
> Making all in libsupc++
> make[4]: Entering directory
> `/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/libsupc++'
> /bin/sh ../libtool --tag CXX --tag disable-shared     --mode=compile
> /cygdrive/p/gcc480snap-install/build/./gcc/xgcc -shared-libgcc
> -B/cygdrive/p/gcc480snap-install/build/./gcc -nostdinc++
> -L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src
> -L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src/.libs
> -B/cygdrive/p/gcc48/i686-pc-cygwin/bin/
> -B/cygdrive/p/gcc48/i686-pc-cygwin/lib/ -isystem
> /cygdrive/p/gcc48/i686-pc-cygwin/include -isystem
> /cygdrive/p/gcc48/i686-pc-cygwin/sys-include
> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/libstdc++-v3/../libgcc
> -I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
> -I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include
> -I/cygdrive/p/gcc480snap-install/
> src/gcc-4.8-20120401/libstdc++-v3/libsupc++  -prefer-pic    -Wall -Wextra
> -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
>  -ffunction-sections -fdata-sections  -frandom-seed=eh_personality.lo -g -O2
> -c -o eh_personality.lo
> ../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc
> libtool: compile:  /cygdrive/p/gcc480snap-install/build/./gcc/xgcc
> -shared-libgcc -B/cygdrive/p/gcc480snap-install/build/./gcc -nostdinc++
> -L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src
> -L/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/src/.libs
> -B/cygdrive/p/gcc48/i686-pc-cygwin/bin/
> -B/cygdrive/p/gcc48/i686-pc-cygwin/lib/ -isystem
> /cygdrive/p/gcc48/i686-pc-cygwin/include -isystem
> /cygdrive/p/gcc48/i686-pc-cygwin/sys-include
> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/libstdc++-v3/../libgcc
> -I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
> -I/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/include
> -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/libstdc++-v3/libsupc++
> -Wall -Wex
> tra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
> -ffunction-sections -fdata-sections -frandom-seed=eh_personality.lo -g -O2
> -c ../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc
> -o eh_personality.o
> ../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc:
> In function '_Unwind_Reason_Code __cxxabiv1::__gxx_personality_sj0(int,
> _Unwind_Action, _Unwind_Exception_Class, _Unwind_Exception*,
> _Unwind_Context*)':
> ../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc:711:1:
> error: verify_flow_info: Block 93 lacks loop_father
> ../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc:711:1:
> error: verify_flow_info: Block 94 lacks loop_father
> ../../../../src/gcc-4.8-20120401/libstdc++-v3/libsupc++/eh_personality.cc:711:1:
> internal compiler error: verify_flow_info failed
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> Makefile:587: recipe for target `eh_personality.lo' failed
> make[4]: *** [eh_personality.lo] Error 1
> make[4]: Leaving directory
> `/cygdrive/p/gcc480snap-install/build/i686-pc-cygwin/libstdc++-v3/libsupc++'
> 

[cxx-conversion] is enable_if ok?

[Pedro Lamarão]

Hello,

currently proposed C++ Coding Conventions imply a very strict 
weird-is-forbidden style, which I like.


But if defining new templates should in general be avoided, I'm unsure 
what is the best path in converting VEC.


VEC interface optimizes element acessors to copy primitive types and 
point-to object types.


If VEC is to be a template class, default accessors in C++ would 
naturally return a (const-)reference-to anything. It would be possible 
to optimize accessors to return a copy instead of a const-reference-to 
with enable_if. All this would allow VEC to be mostly just one thing, 
with small variations in corresponding to VEC_last and VEC_index.


Since enable_if is not part of C++98, it would be added to GCC itself -- 
perhaps in namespace gcc.


This decision will not block work in the branch, of course -- VEC can be 
converted first unoptimized and then reoptimized with whatever tricks 
are allowed.


--
 P.

Re: [cxx-conversion] is enable_if ok?

[Jonathan Wakely]

On 14 April 2012 20:55, Pedro Lamarão wrote:
> Since enable_if is not part of C++98, it would be added to GCC itself --
> perhaps in namespace gcc.

libstdc++ provides __gnu_cxx::__enable_if in 

Re: [cxx-conversion] is enable_if ok?

[Pedro Lamarão]

On 04/14/2012 05:07 PM, Jonathan Wakely wrote:

On 14 April 2012 20:55, Pedro Lamarão wrote:

Since enable_if is not part of C++98, it would be added to GCC itself --
perhaps in namespace gcc.


libstdc++ provides __gnu_cxx::__enable_if in



When vec.h is compiled in stage1 by the host compiler, can we include 
the file you mention?


Or perhaps the suggestion is to optimize with enable_if only after stage1?

--
 P.

Re: [cxx-conversion] is enable_if ok?

[Jonathan Wakely]

On 14 April 2012 21:14, Pedro Lamarão wrote:
> On 04/14/2012 05:07 PM, Jonathan Wakely wrote:
>>
>> On 14 April 2012 20:55, Pedro Lamarão wrote:
>>>
>>> Since enable_if is not part of C++98, it would be added to GCC itself --
>>> perhaps in namespace gcc.
>>
>>
>> libstdc++ provides __gnu_cxx::__enable_if in
>>
>
> When vec.h is compiled in stage1 by the host compiler, can we include the
> file you mention?

I don't know, my point is just that GCC already contains an enable_if
that works in C++03 mode, in addition to std::enable_if, so reusing it
somehow would make more sense than adding a third implementation.

Re: [cxx-conversion] is enable_if ok?

[Marc Glisse]

On Sat, 14 Apr 2012, Pedro Lamarão wrote:


Hello,

currently proposed C++ Coding Conventions imply a very strict 
weird-is-forbidden style, which I like.


But if defining new templates should in general be avoided, I'm unsure what 
is the best path in converting VEC.


VEC interface optimizes element acessors to copy primitive types and point-to 
object types.


If VEC is to be a template class, default accessors in C++ would naturally 
return a (const-)reference-to anything. It would be possible to optimize 
accessors to return a copy instead of a const-reference-to with enable_if. 
All this would allow VEC to be mostly just one thing, with small variations 
in corresponding to VEC_last and VEC_index.


Do you seriously expect it to make a difference? Accessors should be 
inlined to the point of making the value/reference thing irrelevant. If 
std::vector suffers a performance penalty because of this, it is a serious 
optimizer deficiency that should be fixed so all C++ users can benefit.


--
Marc Glisse

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/13/12, Chiheng Xu  wrote:
> On Apr 9, 2012, Richard Guenther  wrote:
>>> Certainly there are cases where the type must be made more specific,
>>> and getting the wrong type here would necessarily be a dynamic check.
>>> However, the number of dynamic checks can be substantially reduced.
>>> To provide a specific example, suppose I have a common_decl *p and
>>> need to do extra work if it is a var_decl.
>>>
>>> do_general_work (p);
>>> if (var_decl *q = p->to_var ())
>>> {
>>>  do_var_work_1 (q);
>>>  do_var_work_2 (q);
>>>  do_var_work_3 (q);
>>>  do_var_work_4 (q);
>>> }
>>>
>>> The only dynamic work is in the pointer conversion.  All other
>>> function calls can be statically typed.
>>
>> Ok.  But the above represents a completely different programming
>> style than what we use currently.  We do
>>
>>  if (is_var_decl (p))
>>{
>>   do_var_work_1 (p);
>> ...
>>}
>>
>> so what I was refering to was static errors we get when we are
>> able to promote function argument / return types to more specific
>> sub-classes.
>
> What about this:
> if(is_var_decl(p)) {
>  var_decl * p_var_decl = (var_decl *) p;
>  do_var_work_1 (p_var_decl);
> }else if(is_type_decl(p)){
>  type_decl * p_type_decl = (type_decl *) p;
>  do_type_work_2 (p_type_decl);
> }else if(is_field_decl(p)){
>  field_decl * p_field_decl = (field_decl *) p;
>  do_field_work_3 (p_field_decl);
> }

That approach will certainly work, but makes the correctness of
the assignment contingent on the condition being right.  If the
condition changes in appropriately, you can get a bug.  Even so,
I think what you suggest is a good intermediate step.

-- 
Lawrence Crowl

Re: [cxx-conversion] is enable_if ok?

[Gabriel Dos Reis]

On Sat, Apr 14, 2012 at 2:55 PM, Pedro Lamarão  wrote:
> Hello,
>
> currently proposed C++ Coding Conventions imply a very strict
> weird-is-forbidden style, which I like.
>
> But if defining new templates should in general be avoided, I'm unsure what
> is the best path in converting VEC.
>
> VEC interface optimizes element acessors to copy primitive types and
> point-to object types.
>
> If VEC is to be a template class, default accessors in C++ would naturally
> return a (const-)reference-to anything. It would be possible to optimize
> accessors to return a copy instead of a const-reference-to with enable_if.
> All this would allow VEC to be mostly just one thing, with small variations
> in corresponding to VEC_last and VEC_index.
>
> Since enable_if is not part of C++98, it would be added to GCC itself --
> perhaps in namespace gcc.
>
> This decision will not block work in the branch, of course -- VEC can be
> converted first unoptimized and then reoptimized with whatever tricks are
> allowed.

One of the requirements is that the code should bootstrap with any
C++03 compiler.
Another requirement is to keep template usage simple.  Those two
requirements to me
mean avoid enable_if.  Of course, maintainers will exercise judgment
on specific cases,
 but as a general guideline, I would suggest to forget them.

-- Gaby

gcc-4.7-20120414 is now available

[gccadmin]

Snapshot gcc-4.7-20120414 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120414/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch 
revision 186455

You'll find:

 gcc-4.7-20120414.tar.bz2 Complete GCC

  MD5=9f9d082b64753d5908690500251fc52e
  SHA1=fbaab50cf607f0153d9bf71d5a135027c1554009

Diffs from 4.7-20120407 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
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: Concurrency items in C++11 status table

[Lawrence Crowl]

On 4/13/12, Torvald Riegel  wrote:
> On Fri, 2012-04-13 at 10:46 +0100, Jonathan Wakely wrote:
> > The table at http://gcc.gnu.org/projects/cxx0x.html indicates
> > most of the concurrency work is not done, but I think the status
> > is better than it shows.
> >
> > If I'm not mistaken strong CAS and bidirectional fences are done.
> >
> > Does anything need to be done for atomics in signal handlers?
> >
> > at_quick_exit() is available in glibc, is anything needed
> > from GCC?
> >
> > Are any compiler changes needed for sequence points, or is
> > it just a re-wording of existing rules to make sense in a
> > multi-threaded world?

The intent of the paper was that there be no change to behavior.
It was motivated by both the apparent inherent confusion with
sequence points and by the concurrency work.  If you find that
there is a change in semantics, please let the C++ committee know.

Data dependency ordering has both a weak implementation and a
strong implementation.  The weak implementation promotes consume
operations to acquire and is suitable to strongly ordered machines.
The strong implementation actually tracks data dependences and is
suitable to weakly ordered machines.  Which does gcc do?  (It would
be worth noting that in the status page.)

>
> We recently spoke about this:
>
> On Thu, 2012-04-12 at 10:15 -0400, Jason Merrill wrote:
> > On 04/11/2012 05:46 PM, Torvald Riegel wrote:
> > > For the mem model and such yes, but for the following too?:
> > > - Dynamic initialization and destruction with concurrency
> >
> > No.  We hold a lock during static local variable initialization,
> > which can lead to deadlock.  We don't support concurrent
> > initialization or destruction of objects with unordered
> > initialization.
> >
> > > - Thread-local storage
> >
> > We have our own version of TLS, but haven't added the standard
> > version.
>
> Jakub pointed out that ctors/dtors for TLS objects could be tricky
> (when combining with dlopen/dlclose).  He further said: So, if
> the standard allows ctors/dtors for TLS vars, I wonder if it can
> be supported at all and how.  What do others do?  Do they just
> ignore dlclose? Or should we just disable dlclosing of libraries
> that have constructed such vars, or defer them until there will
> be just a single thread?

The standard doesn't know about dlclose, but the issue
was addressed in N2425 DRAFT C++ Dynamic Library Support
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2425.html
The essential notion is that a dynamic library author must make
sure that such variables and the threads that use them do not leak
outside the library so that they may be destructed on dlclose.

That notion is puts the burden on library writers, so the net result
of the above statement is that the implementation need do nothing
special about TLS with dlclose.  As a word of caution, that paper
is only a draft.  Dynamic libraries were one of the work items that
were pruned to meet the C++0x schedule.

> > > - Abandoning a process and at_quick_exit
> >
> > No.
>
> But Jakub points out glibc having at_quick_exit.
>
> > > - Allow atomics use in signal handlers
> > > - Sequence points
> >
> > I would guess that these don't require any changes, but haven't
> > verified this.

I believe that no work is required for atomics in signal handlers.
The issue in the standard was to permit what would work anyway.

-- 
Lawrence Crowl

Re: [cxx-conversion] is enable_if ok?

[Lawrence Crowl]

On 4/14/12, Gabriel Dos Reis  wrote:
> On Apr 14, 2012 Pedro Lamarão  wrote:
> > currently proposed C++ Coding Conventions imply a very strict
> > weird-is-forbidden style, which I like.
> >
> > But if defining new templates should in general be avoided,
> > I'm unsure what is the best path in converting VEC.
> >
> > VEC interface optimizes element acessors to copy primitive
> > types and point-to object types.
> >
> > If VEC is to be a template class, default accessors in C++ would
> > naturally return a (const-)reference-to anything. It would be
> > possible to optimize accessors to return a copy instead of a
> > const-reference-to with enable_if.  All this would allow VEC to
> > be mostly just one thing, with small variations in corresponding
> > to VEC_last and VEC_index.
> >
> > Since enable_if is not part of C++98, it would be added to GCC
> > itself -- perhaps in namespace gcc.
> >
> > This decision will not block work in the branch, of course --
> > VEC can be converted first unoptimized and then reoptimized
> > with whatever tricks are allowed.
>
> One of the requirements is that the code should bootstrap with
> any C++03 compiler.  Another requirement is to keep template
> usage simple.  Those two requirements to me mean avoid enable_if.
> Of course, maintainers will exercise judgment on specific cases,
> but as a general guideline, I would suggest to forget them.

Implicit, I think, in Gabriel's statement is that if you really need
enable_if, and make a convincing case, you can get an exception to
the general rule.

To my mind, one of the advantages of enable_if is that customers do
not need to know about it.  It is an internal implementation issue,
and presumably authors using enable_if are comfortable with it.

-- 
Lawrence Crowl