Re: Pascal front-end integration

[Ed Smith-Rowland]

On 1 Mar 2005 at 8:17, James A. Morrison wrote:
Hi,
  I've decided I'm going to try to take the time and cleanup and update
  the
Pascal frontend for gcc and try it get it integrated into the upstream
source. I'm doing this because I wouldn't like to see GPC work with GCC
4+. I don't care at all at supporting GPC on anything less than GCC 4.1
so I've started by ripping out as much obviously compatibility code as I
can and removing any traces of GPC being a separate project.
My guess is that inclusion of Pascal into gcc would give that language
more exposure and would lead to faster development.
By many accounts gcc-4 is getting faster.  It would be nice to see pascal
take advantage of this rather than being marooned on 3.x.
I, for one, am more likely to play with a gpascal that bootstraps with
mainline than to try to build one with, perhaps unusual, dependencies
and some different version of gcc.
I am learning gcc internals slowly (this is a part-time after-work effort :-P)
but I would be interested in helping wherever I can.
  So far I have only accomplished converting lang-options.h to
lang.opt.  I'm going
to continue cleaning up the GPC code, then once I am happy with how the code
looks with respect to the rest of the GCC code, I'm going to get it to
compile with
the current version of GCC mainline.  I'm starting with the boring
conflict happy
whitespace changes first so the code is easier for me to read and so that I can
try to get an idea what the GPC frontend is doing.
Before we get too far with this I think we should keep an eye on a trend in 
gcc
at least through 3.4 and 4.0:  Front ends are increasingly written by hand 
rather
than with flex and bison.  This is true for C++ as of 3.4 and for C as of 4.1.
I'm pretty sure it's true for gfortran too.  I think this is true for gcjx too.
The latter is written in C++ to boot.
My understandng is that gpc uses flex/bison in a p2c - a pascal to C translator.
I would like to know why folks think hand written parsers are better.  My guess 
is that
they are easier to maintain and that they support more lookahead.
A gpascal front end effort might do well to take a hard look at the new front 
ends
for C and C++ (and Java) and consider a rewrite from scratch using these as 
models.
  My current changes are available through bazaar (an arch implementation) which
people can get with:
 baz register-archive http://www.csclub.uwaterloo.ca/~ja2morri/arch 
<http://www.csclub.uwaterloo.ca/%7Eja2morri/arch>
 baz get [EMAIL PROTECTED]/gcc-pascal--mainline--0.3
There is another trend in gcc: a move toward Subversion from CVS.  I 
realize this
is a first-try effort but there would probably be less regret later if we adopt
the standard toolchain.  The decision to go to Subversion was not taken lightly.
Ed Smith-Rowland

Re: Pascal front-end integration

[Ed Smith-Rowland]

James A. Morrison wrote:
Ed Smith-Rowland <[EMAIL PROTECTED]> writes:
 

On 1 Mar 2005 at 8:17, James A. Morrison wrote:
   

Hi,
 I've decided I'm going to try to take the time and cleanup and
update
 the
Pascal frontend for gcc and try it get it integrated into the upstream
source. I'm doing this because I wouldn't like to see GPC work with GCC
4+. I don't care at all at supporting GPC on anything less than GCC 4.1
so I've started by ripping out as much obviously compatibility code as I
can and removing any traces of GPC being a separate project.
 

My guess is that inclusion of Pascal into gcc would give that language
more exposure and would lead to faster development.
By many accounts gcc-4 is getting faster.  It would be nice to see pascal
take advantage of this rather than being marooned on 3.x.
I, for one, am more likely to play with a gpascal that bootstraps with
mainline than to try to build one with, perhaps unusual, dependencies
and some different version of gcc.
I am learning gcc internals slowly (this is a part-time after-work effort :-P)
but I would be interested in helping wherever I can.
   

Grab the source and see what you can do.
 

I will do that.
 

 So far I have only accomplished converting lang-options.h to
lang.opt.  I'm going
to continue cleaning up the GPC code, then once I am happy with how the code
looks with respect to the rest of the GCC code, I'm going to get it to
compile with
the current version of GCC mainline.  I'm starting with the boring
conflict happy
whitespace changes first so the code is easier for me to read and so that I can
try to get an idea what the GPC frontend is doing.
 

Before we get too far with this I think we should keep an eye on a trend in gcc
at least through 3.4 and 4.0:  Front ends are increasingly written by hand 
rather
than with flex and bison.  This is true for C++ as of 3.4 and for C as of 4.1.
I'm pretty sure it's true for gfortran too.  I think this is true for gcjx too.
The latter is written in C++ to boot.
My understandng is that gpc uses flex/bison in a p2c - a pascal to C translator.
I would like to know why folks think hand written parsers are better.  My guess 
is that
they are easier to maintain and that they support more lookahead.
A gpascal front end effort might do well to take a hard look at the new front ends
for C and C++ (and Java) and consider a rewrite from scratch using these as models.
   

Feel free to write your own parser, I have no desire to do that.
 

I have no desire to write my own parser.  I want to steal someone else's 
;-).

I was just wondering what the best one to steal was given the long term 
goals of
1) Integration into GCC-4.x
2) Happy maintainable code
3) Entertainment

In fact, I'm somewhat curious what caused folks to jump into the breach 
with parsers.  From reading the lists it seems to be maintainability and 
stomping out corner case problems for the most part.

Perhaps a parser toolset is emerging that will decouple the front ends 
from the middle and back ends to a greater degree.  I think I will look 
at the new C/C++ parsers and see what's what.

 My current changes are available through bazaar (an arch implementation) which
people can get with:
baz register-archive http://www.csclub.uwaterloo.ca/~ja2morri/arch <http://www.csclub.uwaterloo.ca/%7Eja2morri/arch>
baz get [EMAIL PROTECTED]/gcc-pascal--mainline--0.3
 

There is another trend in gcc: a move toward Subversion from CVS.  I realize 
this
is a first-try effort but there would probably be less regret later if we adopt
the standard toolchain.  The decision to go to Subversion was not taken lightly.
Ed Smith-Rowland
   

I don't think it makes a difference.  If this little project of mine does
start moving I'll put the code in CVS/SVN at that time.  Until then, I'm
taking an opportunity to play with bazaar.
 

I'm all for grabbing new tools and playing with them.  I have a huge 
relational database collection and a script language collection.  In 
fact, I think I'll check out bazaar and arch and start a revision 
control system collection :-).

Ed Smith-Rowland

Re: tag request

[Ed Smith-Rowland]

> I'd like to start hacking on osx gcc. What tag is recommented to 
check out ? Also, what areas > need work most? I'm an experienced 
programmer, but I know jack about gcc.
>

--
alfonso e. urdaneta
www.red82.com - are you ready ?
I would work on mainline.  It bootstraps just fine - usually ;-) - on 
MacOSX.
This is where all the interesting new work goes on (by definition).
Watch the list and see what people are talking about.
One thing of particular interest for MacOSX GCC is getting ObjC++ front end 
integrated
into mainline.  It seems Apple is interested in this but doesn't have time for 
it.  The
GNUStep people are also interested.
Good Luck!
Ed Smith-Rowland

Should Objective-C++ be mentioned in the 4.1 changes.

[Ed Smith-Rowland]

All,

I was looking at the 4.1 changes in
http://gcc.gnu.org/gcc-4.1/changes.html
and noticed that no mention was made of recent Objective-C++ work in 
mainline.


This after I bootstrapped on MacOSX 10.3.9 with
--enable-languages=c,c++,java,objc,obj-c++,f95,treelang

I haven't played around with it much but it built.

I think at least some people would be interested in this and what 
portion of Objective-C++ is  working.



   New Languages and Language specific improvements

Thanks,
Ed Smith-Rowland

Re: Adding the D programming language

[Ed Smith-Rowland]

On 11/13/2005 02:13 PM, Brian Makin wrote:
[snip]
 


If some folks are interested we should talk to the D
people and suggest an acceptable D frontend.


   I for one would be willing to pitch in. 



   There's already one, IIUC:

The link below seems like a more mature effort (it even works in 4.0.*) 
whereas the one avove stopped at around 3.1 by the looks of it.


http://home.earthlink.net/~dvdfrdmn/d/ 



If the 4.0 port of D really works it should go into mainline.

Re: History of GCC

[Ed Smith-Rowland]

On 10/26/2016 01:17 PM, Will Hawkins wrote:

On Wed, Oct 26, 2016 at 1:15 PM, Ian Lance Taylor  wrote:

On Wed, Oct 26, 2016 at 9:31 AM, Will Hawkins  wrote:

Thank you for your response! I don't think that there has to be
controversy to be interesting. Obviously that split/reunification was
important, but I think that there might even be some value in
documenting the minutia of the project's growth. In other words, what
was the process for incorporating each new version of the C++
standard? Who and why did GCC start a frontend for X language? Things
like that.

It is easier to answer specific questions.

There have always been GCC developers that have tracked the evolution
of C++.  The first C++ standard was of course in 1998, at which point
the language was over 10 years old, so there were a lot of C++
language changes before then.  GCC has generally acquired new language
features as they were being adopted into the standard, usually
controlled by options like the current -std=c++1z.  This of course
means that the new features have shifted as the standard has shifted,
but as far as I know that hasn't happened too often.

GCC started as a C compiler.  The C++ frontend was started by Michael
Tiemann around 1987 or so.  It started as a patch and was later
incorporated into the mainline.

The Objective C frontend was started at NeXT.  They originally
intended to keep it proprietary, but when they understood that the GPL
made that impossible they contributed it back.  I forget when the
Objective C++ frontend came in.

Cygnus Support developed the Chill and, later, Java frontends.  The
Chill frontend was removed later, and in fact the Java frontend was
removed just recently.

As I recall Fortran was a hobbyist project that eventually made it in.
There were two competing forks, I think.  I don't remember too much
about that off the top of my head.
There was a split between what would become gfortran and what I still 
think is g95 (www.g95.org).
gfortran was stood up at gcc-4.0 I think.  The earlier g77 front end was 
just too difficult to repair.
Also, Fortran-90, 95 were out with many useful changes and people wanted 
to add them to a new codebase.
The author of g95 developed a pure GPL (not library LGPL version of the 
Fortran runtime.)  This was the split.

This was in mid 2000 or so.

I am a numerics geek.  The fact that gcc has both C++ and Fortran in a 
single kit is very important to me.
I think it maybe one of the last systems that has both.  Certainly it is 
the only Free suite that does.


The Fortran developers* have kept up rather aggressively with 
Fortran-95, 2000, 2008 and TRs.

* my contributions are exclusively to C++, and the C++ linrary.


The Ada frontend was developed at AdaCore.

The Go frontend was written by me, mostly because I like Go and I've
been working on GCC for a long time.  I work at Google, and Go was
developed at Google, but there wouldn't be a GCC Go frontend if I
hadn't decided to write one.

There is a Modula frontend that is always close to getting in.  I
think there is a Pascal frontend out there too, somewhere.  And a D
frontend.

Ian

Wow, thanks Ian! This is awesome stuff! As I read through it, I may
have some additional questions. If I do, would you mind if I emailed
you directly? Thanks again for taking the time to write all this down!
Fascinating!

Will

Re: History of GCC

[Ed Smith-Rowland]

On 10/26/2016 12:31 PM, Will Hawkins wrote:

On Wed, Oct 26, 2016 at 9:07 AM, Ian Lance Taylor  wrote:

On Tue, Oct 25, 2016 at 10:53 PM, Will Hawkins  wrote:

My name is Will Hawkins and I am a longtime user of gcc and admirer of
the project. I hope that this is the proper forum for the question I
am going to ask. If it isn't, please accept my apology and ignore me.

I am a real geek and I love the history behind open source projects.
I've found several good resources about the history of "famous" open
source projects and organizations (including, but definitely not
limited to, the very interesting Free as in Freedom 2.0).

Unfortunately there does not appear to be a good history of the
awesome and fundamental GCC project. I know that there is a page on
the wiki (https://gcc.gnu.org/wiki/History) but that is really the
best that I can find.

Am I missing something? Are there good anecdotes about the history of
the development of GCC that you think I might find interesting? Any
pointers would be really great!

Thanks for taking the time to read my questions. Thanks in advance for
any information that you have to offer. I really appreciate everyone's
effort to make such a great compiler suite. It's only with such a
great compiler that all our other open source projects are able to
succeed!

There is some history and links at
https://en.wikipedia.org/wiki/GNU_Compiler_Collection .

In my opinion, the history of GCC is not really one of drama or even
anecdotes, except for the EGCS split.  There are plenty of people who
work on GCC out of personal interest, but for decades now the majority
of work on GCC has been by people paid to work on it.  I expect that
the result is less interesting as history and more interesting as
software.

Ian

Ian,

Thank you for your response! I don't think that there has to be
controversy to be interesting. Obviously that split/reunification was
important, but I think that there might even be some value in
documenting the minutia of the project's growth. In other words, what
was the process for incorporating each new version of the C++
standard? Who and why did GCC start a frontend for X language? Things
like that.
The C++ standards committee requires that each feature added be tried in 
at least one existing implementation before ratification.
There are experimental "standards" starting with TR1 back in 2005 or so 
and continuing up through today. gcc developers are very quick to read 
the papers and start developing (assuming the idea didn't already come 
from us in the first place).  This implementation experience feeds into 
the standards process.  Basically, g++ and libstdc++ have been very 
important testing ground for the C++ standard ideas.


Speaking for myself, I got sucked in in 2005 after seeing Pete Becker's 
book on Standard Library Extensions (TR1).  I love numerics and there 
was a set of mathematical functions that I had implemented for myself 
for school and other projects.  I decided to put that into libstdc++ and 
I've been hooked ever since.  I have added some containers 
(forward_list).  I even have delved into the front end such as adding 
user-defined literals.


I am a crazy hobbyist.  Possibly one of the few.

Ed

Thanks again for your response!

Will

Re: GCC version bikeshedding

[Ed Smith-Rowland]

On 07/31/2014 07:03 PM, Ian Lance Taylor wrote:

On Thu, Jul 31, 2014 at 4:52 AM, NightStrike  wrote:

One thing you might want to consider is that with the typical X.Y.Z
versioning of most GNU projects, changing X allows breaking
compatibility in a significant way with previous versions.  While Z
fixes regressions and Y adds new features, X is a place to make
infrequent but paradigm shifting changes that are unconstrained by a
desire to stay backwards compatible with older values of X.

By going to what is essentially a Y.Z.0 release mechanism, you lose
that ability to some degree.  Maybe that's ok in a mature project like
GCC.

I believe the GCC project has become too large to be able to usefully
speak about breaking compatibility with previous versions.  There are
too many different moving parts.  We break compatibility in various
minor ways with every release.  We try pretty hard to never break
compatibility in a big way.  Historically, as far as I can recall, the
GCC major release number has never indicated a compatibility break
that was relevant to most users.

Ian

What about bumping the default compiler front end versions to C11 or 
C++11 or C++14?  Even for bootstrap?

There may be some breaking changes that are larger than the usual.

FWIW, I do not object to going to 5.0, 6.0.

Ed

Re: Implementation of Zeta functions in libstdc++

[Ed Smith-Rowland]

On 07/31/2014 01:03 PM, Florian Goth wrote:


Hi!
I've noticed that gcc's libstdc++ has implementations of
the zeta function and the hurwitz-zeta functions.
Is there any work going on with them?
Would an implementation of hurwitz_zeta in terms of the Polylogarithm be 
helpful?
Thanks,
Florian.
  

The tr1 math functions are in deep maintenance mode - generally we don't 
enhance them.
On the other hand, there is TR 29124 Special math functions which is 
essentially the same thing.


To contribute you need Copyright assignment.
See https://gcc.gnu.org/contribute.html.

Otherwise I, for one, would be interested in this contribution.

Ed

Re: Implementation of Zeta functions in libstdc++

[Ed Smith-Rowland]

On 08/03/2014 08:28 PM, Florian Goth wrote:

Hi!
Thanks Ed for the kind reception of this idea.
To show what I have done so far I have set up a git repository here:
https://github.com/CaptainSifff/zeta
Obviously it is not yet in a state where it looks like sth. from the standard 
library; it still uses my conventions right now.
This commit
https://github.com/CaptainSifff/zeta/commit/6f4d70975f0a064a1d551fd5319f5ac3391f4234
gives an example where the old implementation failed and which essentially led 
me to recode all this.
So, what do you think,
What it be nice to have that functionality in gcc and is it worthwhile to patch 
it up for the std library?
I would be willing to do the work and get a copyright assignment.
  
Another thing:

I fiddled with the code for the evaluation of the Riemann Zeta function.
By removing a lot of calls to special functions in the innermost loop I
could speed it up by about a factor of 3 on my machines(core2 + core-i7).
The commits are
https://github.com/CaptainSifff/zeta/commit/d1d32f2ac2422d9c5408e1b850984dcb3cd2aeb6
and to clean things up:
https://github.com/CaptainSifff/zeta/commit/e48ba770a0591af8d56150401a50807218c00026
The basic idea is to replace the evaluation of the binomial coefficient via 
exp(log(gamma(x)))
by a recursive relation of the binomial coefficient. This does not worsen the 
numerical stability since
all intermediate results are perfectly representable. Of course that hard 
boundary where the result of the binomial coefficient is not
representable anymore is still present.
  


Florian.


Florian,

Great work!  Please continue your work.  The polylog function would also 
make a nice extension to the function library in it's own right.
Please begin you copyright assignment quickly - that can take a long 
time to get through.


Finally, this is a C++ library issue so we should move our conversation 
there.


Thank you,
Ed

Re: Is this a compiler bug?

[Ed Smith-Rowland]

On 09/21/2014 09:56 PM, Steve Kargl wrote:

+ is a binary operator.  0x3ffe is a hexidecimal-constant according
to 6.6.4.1 in n1256.pdf.  63 is, of course, a decimal-constant.


Also, a hex floating point uses p as an exponent for this reason...
These should just be adding integers.

i = 0x3ffe+63; /* integral */

i = 0x3ffp+63; /* floating point */

Post the PR.
I did a lot of stuff in this area for C++11 user-defined literals.
I either caused it of I might be able to help.

Ed

Re: 404 @ https://gcc.gnu.org/gcc-5/

[Ed Smith-Rowland]

On 12/27/2014 08:03 PM, Jonathan Wakely wrote:

On 28 December 2014 at 00:08, Olaf van der Spek  wrote:

On 26-12-2014 1:52, Jonathan Wakely wrote:

On 25 December 2014 at 16:28, Olaf van der Spek wrote:

Hi,

https://gcc.gnu.org/ links to https://gcc.gnu.org/gcc-5/ (GCC 5 C++14
language feature-complete [2014-12-23]) which doesn't exist.


It should probably be https://gcc.gnu.org/gcc-5/status.html

(As already said, I meant https://gcc.gnu.org/gcc-5/changes.html there)


I don't think that's right, it should link to a page like
https://gcc.gnu.org/gcc-4.8/

Ah, I don't think that will exist until it's released.


Important: Because the final ISO C++14 standard was only recently
published, GCC's support is experimental.


Is C++11 support no longer experimental?


That hasn't changed yet, but it should be announced on
https://gcc.gnu.org/gcc-5/status.html when it does.


Okay, but shouldn't that be reflected in the announcement?
I doesn't mention the experimental status at all.

Which announcement, the C++14 one?
Why should that say anything about the status of C++11?


The note about C++14 conformance is great as it stands modulo link errors.

The note on C++14 conformance referred to is not the place for this but: 
is our C++11 support really less tested and more experimental than our 
C++03 support at this point?  One thing I can think of might be gcc 
bootstrap.


I could be wrong but I sense the subtext of the OP is perhaps a request 
for a roadmap and guidance for which C++ language version is best supported.
We can't offer a roadmap on default language until we have a big 
conversation and exploration of technical issues.


I imagine we should at least wait until C++11 ABI churn has died down.
We need to build gcc with C++11/C++14 turned on to work out build kinks 
(I admit I haven't pushed this as hard as I had hoped).

Then a big talk of gcc version - default C++ version.

Ed

Re: 404 @ https://gcc.gnu.org/gcc-5/

[Ed Smith-Rowland]

On 12/30/2014 07:50 AM, Olaf van der Spek wrote:

On 29-12-2014 16:34, Ed Smith-Rowland wrote:
The note about C++14 conformance is great as it stands modulo link 
errors.


Why is it great to not mention the experimental qualifier?

Do all files / libraries have to be compiled with the same -std option?
If so, this option causes ABI issues by itself.

Olaf


I should have replaced 'conformance' with 'feature completeness' in my 
sentences.
The words in the message indicate 'features'.  The word experimental 
appears in bold.


My understanding is that the C++11 ABI changes to string, list, 
ios_base::failure (are there others?) that have been queued for a while 
have been put into gcc5.  This is the big release.  There was a message 
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01669.html (and 
subsequent) on this.
Check https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00268.html for 
std::list.
Check https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01750.html for 
std::ios_base::failure.


I'm quite sure that once the ABI issues have been stabilized appropriate 
formal announcements and documentation will appear on this subject.


Ed

[C++-0X] User-defined literals

[Ed Smith-Rowland]

Greetings,

I am taking a new shot at user-defined literals.
Compared to the previous attempt:
  * I have altered libcpp so that it tokenizes user defined literals in 
one chunk properly.

  * I have started work on new tree nodes and accessors.
  * I have (or am trying to) refine the checks for argument and 
template parameter.


I would like to check that template literal operators have the specific 
non-type parameter pack:

template
  Foo operator"" sluggo();

I looked through the internals documentation and didn't see much on 
this.  Could anyone give me some pointers?


Also, is there any preference for using VEC vs. TREE_CHAIN for making 
trees and accessing them?  Is one sort of "modern"?


Finally I am using compparms to verify that a literal operator argument 
list conforms to strings like:

(const char*)
(const char*, std::size_t)
(const wchar_t*, std::size_t)
...
I cant get them to work.  I built a set of global trees for the argument 
types that I want to check.  The char and number tests work.
I use things like this to build the argument lists (I neglect the return 
type).

userdef_lit_char16_str_type
 = build_function_type_list (void_type_node, char16_array_type_node,
 size_type_node, NULL_TREE);
I'm hoping that this matches
(const char16_t*, std::size_t)
but it doesn't.

Ideas?

Thanks,

Ed Smith-Rowland

Re: [C++-0X] User-defined literals, gsoc

[Ed Smith-Rowland]

On 03/29/2011 10:05 AM, Levon Haykazyan wrote:

Hi Ed,

I am working on a proposal to implement user-defined literals as a Google
Summer of Code project. I was unaware that someone was already working on
it. If you have already done some work, maybe it is better for me to pick
another project. Or maybe you would be interested in mentoring me and we
could combine our efforts.

Kind regards,
Levon


- Original Message -
From: Ed Smith-Rowland<3dw...@verizon.net>
To: gcc@gcc.gnu.org
Subject: [C++-0X] User-defined literals
Date: Mon, 28 Mar 2011 20:13:19 -0400


Greetings,

I am taking a new shot at user-defined literals.
Compared to the previous attempt:
* I have altered libcpp so that it tokenizes user defined
literals in one chunk properly.
* I have started work on new tree nodes and accessors.
* I have (or am trying to) refine the checks for argument and
template parameter.

I would like to check that template literal operators have the
specific non-type parameter pack:
template
Foo operator"" sluggo();

I looked through the internals documentation and didn't see much on
this.  Could anyone give me some pointers?

Also, is there any preference for using VEC vs. TREE_CHAIN for
making trees and accessing them?  Is one sort of "modern"?

Finally I am using compparms to verify that a literal operator
argument list conforms to strings like:
(const char*)
(const char*, std::size_t)
(const wchar_t*, std::size_t)
...
I cant get them to work.  I built a set of global trees for the
argument types that I want to check.  The char and number tests
work.
I use things like this to build the argument lists (I neglect the
return type).
  userdef_lit_char16_str_type
   = build_function_type_list (void_type_node, char16_array_type_node,
   size_type_node, NULL_TREE);
I'm hoping that this matches
(const char16_t*, std::size_t)
but it doesn't.

Ideas?

Thanks,

Ed Smith-Rowland



Levon,

I would be happy to share what I've got.  Let me clean it up some and 
I'll post it tomorrow.  Then we'll see if

a. You want to pick another project
b. Pick over what I have and start from there
c. Start over on your own ;-)

There is a good amount of work left to do I think.  I have to admit I'm 
a newbie on gcc internals.  You may be in a better position to finish 
this time-wise.


I am interested in seeing this get in so we can all play with it before 
the standard comes out.  There are some who would pull it out of the 
standard for want of implementation experience.


Ed

[C++0x]User-defined literals - building a call to template function.

[Ed Smith-Rowland]

Greetings,

I am working on user-defined literals and have much of it working.
I am stuck on template function calls though.

If I have a literal oprator like this:

template
  int
  operator"" _abc()
  { return 42 + sizeof...(Chars); }

Then later on I see this:
  int j = 123_abc;

I need to look up the function
  operator"" _abc();

I can find the function with cp_parser_lookup_name no problem.  It is 
even recognized as a template function.


I need to build the call
  operator"" _abc<'1', '2', '3'>();

My problem is I can't fill the template argument pack.
I tried tsubst and all I get is:
  operator"" _abc<>();

Any hints on how to fill the template agument list?

My patch is over on gcc-patches.

Thanks,

Ed Smith-Rowland.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Ed Smith-Rowland]

On 11/05/2011 08:36 AM, David Brown wrote:

On 04/11/11 20:35, 3dw...@verizon.net wrote:

Greetings,

Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in the preprocessor.  The C++11 spec stipulates
that any suffix that is recognized by the implementation is not
allowable as a user-defined literal suffix in c++.  This prevents C++
from hijacking 123LL, 1.234L, etc.  On the other hand, there are
several numeric literal suffixes that are recognized and used as gnu
extensions.

One class of suffixes stands out in this connection: fixed-point
literals.  These end in 'k' or 'r' and can optionally be unsigned by
starting with 'u' and optionally have a size 'h', 'l', 'll'.  The
difference for these suffixes is that fixed-point literals are
explicitly rejected by the c++ front end.  Attempts to use such
literals: int i= 1.23k; results in 'error: fixed-point types not
supported in C++'.

So I ask the question:  Should I make a simple change to libcpp to
allow fixed-point literal suffixes to pass to the user-defined
literal code in c++11 mode?

Thanks,

Ed Smith-Rowland

P.S. There are other suffixes that might be reclaimed as well such as
'i', 'I', 'j', 'J' for complex integral or floating point imaginary
numbers and others.  These might be more difficult or impossible to
reclaim for C++11 because these might be allowed and used in gnu-C++
and it might break existing code.



gcc has a tradition of allowing C-compatible features from C++ to be 
supported in C, and useful features from C to be supported in C++. 
Typically these being life as gcc extensions, but they sometimes move 
into the standards (an easy example being gcc's support for C++ 
comments in C from long before C99 came out).  An example is gcc's 
support for C99-style "_Complex" floating point types in C++.


Is there a good reason why the fixed point types (and decimal types, 
and extended float types) are not supported in C++ as a gcc 
extension?  It strikes me that from the users' viewpoint it would be 
best for these features to be available in C++ as well.  If the actual 
implementation of this would be difficult (I have no idea of the 
effort involved here), then the next best thing is to reserve the 
suffixes to avoid breaking things in the future, and to avoid user 
confusion.




I think that fixed-point numbers would be an excellent addition to C++.  
The question is how to do it and what the semantics are.


On one hand we could probably let the C fixed-point types and keywords 
and literals work in C++. IIRC C fixed-point extensions are rather 
limited in terms of what sizes and precisions are allowed.


On the other hand, if we let C++ user-defined literals handle the 
literals then this opens the door to a pure library solution that would 
allow arbitrary size and precision and base for example.  I tend to 
think the C++ committee would be more in favor of this because they tend 
to push library changes over language enhancements for flexibility.  
This would likely be a template library of some kind.


Maybe there's a way to support both.  IIRC the template specializations 
for complex use the corresponding _Complex types under the hood.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Ed Smith-Rowland]

On 11/06/2011 10:40 AM, Jonathan Wakely wrote:

On 6 November 2011 15:03, David Brown wrote:


What usually happens is that if C has claimed a new keyword already
C++ will reuse it.  When C++ has added a new keyword such as
static_assert the C committee has preferred to add keywords in the
reserved namespace.  That's an engineering decision, based on the risk
of breaking user code and weighed up against the reward of having more
convenient names.  The C++ committee are generally less fond of
macros, so less willing to solve the problem via e.g.
#define static_assert _Static_assert


As a programmer, when I write portable code in C I want it to be valid C++
as well.  This gives the most flexibility, and the most efficient use of my
code.  I don't want to have to re-write code to do the same thing in each
language, or to re-learn the differences.

So to make "_Fract" and "_Accum" really useful, I need to be able to use it
in C and C++ code, and know that the types are compatible across the two
languages, and that the generated code will be equally efficient. Frankly,
as a user I don't really care whether it is implemented by a C++ library, a
gcc extension, mind-numbing macros, or whatever.  It is absolutely fine if
the details are hidden within a "stdfix.h" header file.  But what I /don't/
want to end up with is a type called "signed short _Fract" in C and
"_fract<8>" in C++, or being unable to pass data between the languages, or
having to have C++ call external C functions just to get efficient
implementations.

I think a better example is atomics support in C++11 and C11, where
std::atomic  aka std::atomic_int can be exactly the same
representation as _Atomic int and are compatible, but the C++ library
solution also allows std::atomic  which C doesn't.  A *lot* of
work went into ensuring the C++ atomics support included a subset that
would be implementable in C.

Why couldn't the same be done for _Fract?

I think it would be very possible to have a general template library for 
C++ that would handle a range of sizes and granularities.  There would 
be a few combinations that would correspond to the C types.  These would 
use the hardware implementation by template specialization.


I think the deeper issue is that there are two communities who are 
interested in fixed-point math.  1. Embedded system folks who need an 
efficient replacement for floating point that matches their hardware.  
2. Systems programmers and financial types who want fixed-point like in 
COBOL and Ada where you specify granularity and number of digits.  I'm 
saying both groups can be accommodated with care.  I think even source 
compatibility could be achieved with home headers.

Re: builtin gamma function

[Ed Smith-Rowland]

On 11/15/2011 08:51 AM, James Hirschorn wrote:

I guess "fold" means do the computation at compile time?

No, it is being called with a variable. That is interesting that libc has a
gamma function. I will have to track down the implementation ...

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com]
Sent: Tuesday, November 15, 2011 1:58 AM
To: James Hirschorn
Cc: gcc@gcc.gnu.org; james.hirsch...@gmail.com
Subject: Re: builtin gamma function

James Hirschorn  writes:


I have noticed that the builtin gamma function is very accurate and
extremely fast. Can someone tell me where to find the source code for the
implementation?

Are you calling it on a constant?  Because gcc will fold gamma applied
to a constant which meets certain characteristics.

If you aren't calling it on a constant, then you are getting the
function from your libc.  gcc does not itself include an implementation
of the gamma function.

Ian


The Lancsos algorithm should be pretty fast.  OTOH there are a few logs 
and some divisions.
I'm betting they have a polynomial fit from 0 to 1 and then do 
\Gamma(x+1) = x\Gamma(x) or something.


Also, Maybe we could use constexpr in C++11 mode in some cases.

Re: The future of concepts

[Ed Smith-Rowland]

James Dennett wrote:

On Tue, Jul 28, 2009 at 3:01 AM, Piotr Wyderski wrote:
  

Concepts have recently been removed from the C++0x Standard Draft.
Will the concepts branch be discontinued?



I hope not.  Concepts will be "finished" and re-added to C++, and it
would be immensely helpful in that effort if there were a version of
g++ with stronger Concepts support than ConceptGCC had.

-- James

  
We need a gcc branch for concepts.  One of the major complaints on 
concepts and one of the major contributors to its being dropped is that 
there is no implementation experience.  There was no implementation of 
sufficient quality and availability to give compiler developers 
confidence and point to wrinkles in the definition and users time to 
learn and play.  It will take a good couple of years to get one working.


That leaves open the question of whether the ConceptGCC branch is the 
one.  I just don't know.  Maybe someone should start over.  I think aim 
for simplicity.  That was another issue I think: 
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2906.pdf 
(Stroustrup)


Ed

Re: [lambda] Segmentation fault in simple lambda program

[Ed Smith-Rowland]

Adam Butcher wrote:

Hi

Esben Mose Hansen writes:
  

this program SEGFAULTs

#include 

int main() {
  int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
  const std::size_t nn = sizeof(numbers)/sizeof(int);
  int sum = 0;
  int f = 5;
  std::for_each(&numbers[0], &numbers[nn],  [&]  (int n)  {
sum += n * f;
  });

}
...
I am completely new to gcc hacking, just
dying to get lambda into gcc 4.5 :)



Me to on both counts!  So much so that I've got a working copy of the latest 
lambda branch, svnmerged the latest 4.5.0
trunk into it, fixed a few build issues and started poking around.  I have 
never ventured into gcc internals before so
its all a bit alien at the mo.

  

On Thursday 30 April 2009 19:19:31 Ian wrote:


When I try to specify the capture it works ((&sum, &f) works too but f is
const):

#include 

int
main(void)
{
  int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
  const std::size_t nn = sizeof(numbers)/sizeof(int);
  int sum = 0;
  int f = 5;

  //std::for_each(&numbers[0], &numbers[nn], [&](int n) { sum += n * f; });

  std::for_each(&numbers[0], &numbers[nn], [&sum, f](int n) { sum += n * f;
});

  return 0;
}
  

 Yup. In fact, almost any other capture block than the [&] works :) I will try
 to look at those tree options when I get sober again.



It is crashing when invoking a copied 'implicit capture' lambda.  The same 
occurs with:

  int main()
  {
 char i,j,k;
 auto const& f = [&] { i = 1; j = 2; k = 3; };
 auto g = f;
 g();
 return i+j+k;
  }

With explicit captures (i.e. specifying [&i,&j,&k] instead of [&] above) it 
works fine.  Also using f() (in place of
g()) is fine so the code in the lambda and the call to it must be okay.  So I 
started looking into the instance data.

The resulting lambda class in the above program is generated by the compiler to 
look something like the following in
name and structure:

   struct __lambda0
   {
  char &i,&j,&k;
  void operator() () const
  {
 i = 1; j = 2; k = 3;
  }
   };

Looking at the implementation in gcc/cp/{class.c,parser.c,semantics.c} it seems 
that, in implicit capture mode,
references to enclosing scope identifiers are retrospectively added to the 
lambda class on first use in the lambda
body.  This made me worry about the class structure changing as you progress through the parse of the lambda body. 
I.e. at the start of the body nothing is captured -- since nothing is referenced.  As you meet enclosing scope

references, each is added as a capture member to the lambda class.  Is this 
okay or has something already decided on
the size and structure of the class?  I figured (almost certainly naively and 
incorrectly) that it ought to be similar
to the difference between:

   struct X
   {
  int i;
  void init_i() { i = 1; }
   };

and

   struct X
   {
  void init_i() { i = 1; }
  int i;
   };

I changed the program above to check the sizes of the generated lambda class 
and it is indeed as expected (three
pointers). So the class has the correct size -- why does it not copy?  Surely a 
bitwise copy in this case is
sufficient and that ought to be auto-generated.  -- Except we're in compiler 
land here -- are we supposed to do the
auto-generating?  To test the theory I added

 memcpy(&g,&f,sizeof g);

after the assignment (auto g = f) to force the instance data to be copied from 
f to g.  It worked!  So why is the
compiler not generating suitable code for the lambda class copy -- the size is 
right, but no copy of instance data is
made -- maybe its already decided that the size is zero (as it was before the 
lambda body) and generated 'do-nothing'
copy constructors?

I had a poke around in gcc/cp/{class.c,parser.c,semantics.c} and believe I have 
worked around the issue -- the proper
solution I don't think is as straight-forward (or maybe its more 
straight-forward for a gcc guru?).

Note that the following diff hunk is after an svnmerge of trunk commits into my 
wc of the lambda branch so offsets
will likely be wrong.  I would give a full diff but my wc is in rather a messy 
state at the mo.  I have no idea
whether there are any nasty side effects to doing this but it seems to do the 
copy correctly afterwards.  I have not
looked into it much further at the mo.  Thought I'd just post my findings.

### snip ##
--- gcc/cp/parser.c (revision 150148)
+++ gcc/cp/parser.c (working copy)
@@ -6936,6 +6991,24 @@

 cp_parser_lambda_body (parser, lambda_expr);

+/* relayout again -- to allow for implicit
+ * parameters to have been added to the capture if it was a
+ * 'default capture' -- note that this would not be necessary if
+ * the stack-pointer variant was implemented -- since the layout
+ * would be known.
+ * Relayingout here might have nasty effect if one were to query
+ * sizeof *this from within the body -- would that even be
+ * possible -- *this would refer to the lambda or 

Re: The future of concepts

[Ed Smith-Rowland]

Jason Merrill wrote:

On 07/28/2009 10:47 AM, Ed Smith-Rowland wrote:

We need a gcc branch for concepts.


Probably, if someone is working on them, just as for any ongoing project.


That leaves open the question of whether the ConceptGCC branch is the
one.


No.  Doug felt that much of ConceptGCC needed to be rewritten; the 
ConceptGCC branch is just a place to store the existing work for later 
reference.
That effort did look dead.  It seemed to me like a clean slate would be 
nice.


One idea I had was to look at the metaprogramming pseudo concepts that 
seem to be in the library already and beefing those up.  Maybe that plus 
a tiny amount of core language secret sauce would be the best approach 
for concepts.


There is a cxx0x-concepts-branch, but no work has been done on it. 
Probably when someone starts serious work on reimplementing concepts 
we'll create a new branch.  I don't currently have any plans to work 
on concepts, as there are plenty of other things to work on that will 
be in C++0x.

I agree.  There's constexpr, lambdas, nullptr, etc.

Then there's library stuff like regex mostly.

I was thinking we'd have a lot of green check marks for most of C++-0x 
when it finally comes out.  I think other compilers will too.  There 
won't be hardly any latency at all between ratification and good and 
broad support for C++-0x.  That's nothing to sneeze at.


Jason

Re: apple blocks extension

[Ed Smith-Rowland]

Richard Henderson wrote:

On 09/15/2009 08:28 AM, Vincent R. wrote:

I just was curious to know if closures in apple gcc(called blocks from
what I read) is
also in mainline.
What is the status about this extension ?


It is unlikely that this will ever be brought into GCC, since
it appears to be largely identical to the C++0x Lambda feature.

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf


r~

I agree that it is superfluous for C++ at this stage but it might be 
nice for Objective-C (regular C) although Objective-C++ will then have 
to be taught how to deal with it somehow anyway.


OTOH, with lambdas it might be more easy to put this in.*  It is 
probably just a special case of lambdas.  We'd have to find out which 
one of course.  I think syntactically it shouldn't be too bad.**


In general, and this has come up before, there are other things in 
Objective-C 2.0 that we don't have.  IIRC the Apple trees left behind 
are a little old and not in good shape.  What are the licensing issues 
for borrowing from LLVM leaving aside the technical issues?


ed

* Or not.  I think C++ lambdas are implemented as a little class of some 
type which might make C mad.


** I was noticing that C++ lambdas and Obj-C message passing syntax 
collides a little.

Added myself to MAINTAINERS

[Ed Smith-Rowland]

I added myself (Edward Smith-Rowland) to MAINTAINERS (Write After Approval).

I work on libstdc++.

Thanks all, especially my mentors Paolo Carlini and Benjamin Kosnik ;-),

Ed Smith-Rowland

Index: libstdc++-v3/include/precompiled/stdc++.h
===
--- libstdc++-v3/include/precompiled/stdc++.h   (revision 152686)
+++ libstdc++-v3/include/precompiled/stdc++.h   (working copy)
@@ -101,6 +101,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
Index: libstdc++-v3/ChangeLog
===
--- libstdc++-v3/ChangeLog  (revision 152686)
+++ libstdc++-v3/ChangeLog  (working copy)
@@ -1,3 +1,7 @@
+2009-10-13  Edward Smith-Rowland  <3dw...@verizon.net>
+
+   * include/precompiled/stdc++.h: Include  for 
completeness.
+
 2009-10-12  Paolo Carlini  
 
* include/bits/random.h (class linear_congruential_engine,
Index: MAINTAINERS
===
--- MAINTAINERS (revision 152686)
+++ MAINTAINERS (working copy)
@@ -454,6 +454,7 @@
 Johannes Singler   sing...@ira.uka.de
 Franz Sirl franz.sirl-ker...@lauterbach.com
 Jan Sjodin jan.sjo...@amd.com
+Edward Smith-Rowland   3dw...@verizon.net
 Michael Sokolovmsoko...@ivan.harhan.org
 Richard Stallman   r...@gnu.org
 Basile Starynkevitch   bas...@starynkevitch.net
Index: gcc/configure
===
--- gcc/configure   (revision 152686)
+++ gcc/configure   (working copy)
@@ -22917,6 +22917,37 @@
 
 fi
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for swap 
suffix" >&5
+$as_echo_n "checking assembler for swap suffix... " >&6; }
+if test "${gcc_cv_as_ix86_swap+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_ix86_swap=no
+  if test x$gcc_cv_as != x; then
+echo 'movl.s %esp, %ebp' > conftest.s
+if { ac_try='$gcc_cv_as  -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+then
+   gcc_cv_as_ix86_swap=yes
+else
+  echo "configure: failed program was" >&5
+  cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_ix86_swap" >&5
+$as_echo "$gcc_cv_as_ix86_swap" >&6; }
+if test $gcc_cv_as_ix86_swap = yes; then
+
+$as_echo "#define HAVE_AS_IX86_SWAP 1" >>confdefs.h
+
+fi
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for different 
section symbol subtraction" >&5
 $as_echo_n "checking assembler for different section symbol subtraction... " 
>&6; }
 if test "${gcc_cv_as_ix86_diff_sect_delta+set}" = set; then :
Index: gcc/config.in
===
--- gcc/config.in   (revision 152686)
+++ gcc/config.in   (working copy)
@@ -315,6 +315,12 @@
 #endif
 
 
+/* Define if your assembler supports the swap suffix. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_IX86_SWAP
+#endif
+
+
 /* Define if your assembler supports the lituse_jsrdirect relocation. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_JSRDIRECT_RELOCS

Question on C++-0x constexpr

[Ed Smith-Rowland]

I was toying around with constexpr in the standard library and tripped 
on this:


// /bin/bin/g++ -std=c++0x -c template_constexpr.cpp

template
class A
{
 static constexpr int foo() { return 666; }
};

template
class B
{
 static constexpr int foo() { return e.foo(); }  //  Should the 
compiler be able to noodle this out?

 static constexpr int bar() { return E::foo(); }  //  Works fine.
private:
 E e;
};

template_constexpr.cpp: In static member function 'static int B::foo()':
template_constexpr.cpp:16:5: error: invalid use of member 'B::e' in 
static member function

template_constexpr.cpp:13:39: error: from this location


Question, if you can use a member access operator to access a static 
member, shouldn't constexpr work through that method too?


Thanks,

Ed Smith-Rowland

Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)

[Ed Smith-Rowland]

Kaveh R. GHAZI wrote:

A prerelease tarball of the upcoming mpc-0.8 is available here:
http://www.multiprecision.org/mpc/download/mpc-0.8-dev.tar.gz

This release is feature complete with respect to C99 and GCC's needs.
So I expect to make this version be the one made mandatory for the
gcc-4.5 release.  If there are any remaining bugs especially
portability problems to GCC's primary or secondary platforms, I'd like
to get those reported and fixed before this release is final.

Please test this MPC package and report back the results of running
"make check" along with your target triplet, the compiler version you
used, and the versions of gmp/mpfr used to compile it.  You do not
necessarily need to bootstrap mainline GCC with this MPC, but if you
have the spare time and cycles it would be nice too.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  gh...@caip.rutgers.edu

  

I'm on MacOSX 10.3

MacOSX:~/Tarballs/mpc-0.8-dev ed$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)

The -Werror kills it.
This warning is familiar.

MacOSX:~/Tarballs/mpc-0.8-dev ed$ make
make  all-recursive
make[1]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev'
Making all in src
make[2]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev/src'
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I..-pedantic -Wno-long-long -Wall -Werror -O2 -pedantic -mpowerpc 
-no-cpp-precomp -force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP -MF 
.deps/abs.Tpo -c -o abs.lo abs.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -pedantic -Wno-long-long 
-Wall -Werror -O2 -pedantic -mpowerpc -no-cpp-precomp 
-force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP -MF .deps/abs.Tpo -c 
abs.c  -fno-common -DPIC -o .libs/abs.o

In file included from mpc-impl.h:33,
from abs.c:22:
mpc.h:148: warning: use of `long double' type; its size may change in a 
future release

mpc.h:148: warning: (Long double usage is reported only once for each file.
mpc.h:148: warning: To disable this warning, use -Wno-long-double.)
make[2]: *** [abs.lo] Error 1
make[2]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev'
make: *** [all] Error 2

Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)

[Ed Smith-Rowland]

Ed Smith-Rowland wrote:

Kaveh R. GHAZI wrote:

A prerelease tarball of the upcoming mpc-0.8 is available here:
http://www.multiprecision.org/mpc/download/mpc-0.8-dev.tar.gz

This release is feature complete with respect to C99 and GCC's needs.
So I expect to make this version be the one made mandatory for the
gcc-4.5 release.  If there are any remaining bugs especially
portability problems to GCC's primary or secondary platforms, I'd like
to get those reported and fixed before this release is final.

Please test this MPC package and report back the results of running
"make check" along with your target triplet, the compiler version you
used, and the versions of gmp/mpfr used to compile it.  You do not
necessarily need to bootstrap mainline GCC with this MPC, but if you
have the spare time and cycles it would be nice too.

Thanks,
--Kaveh
--
Kaveh R. Ghazigh...@caip.rutgers.edu

  

I'm on MacOSX 10.3

MacOSX:~/Tarballs/mpc-0.8-dev ed$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)

The -Werror kills it.
This warning is familiar.

MacOSX:~/Tarballs/mpc-0.8-dev ed$ make
make  all-recursive
make[1]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev'
Making all in src
make[2]: Entering directory `/Users/ed/Tarballs/mpc-0.8-dev/src'
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I..-pedantic -Wno-long-long -Wall -Werror -O2 -pedantic -mpowerpc 
-no-cpp-precomp -force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP 
-MF .deps/abs.Tpo -c -o abs.lo abs.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -pedantic 
-Wno-long-long -Wall -Werror -O2 -pedantic -mpowerpc -no-cpp-precomp 
-force_cpusubtype_ALL -mcpu=7450 -MT abs.lo -MD -MP -MF .deps/abs.Tpo 
-c abs.c  -fno-common -DPIC -o .libs/abs.o

In file included from mpc-impl.h:33,
from abs.c:22:
mpc.h:148: warning: use of `long double' type; its size may change in 
a future release
mpc.h:148: warning: (Long double usage is reported only once for each 
file.

mpc.h:148: warning: To disable this warning, use -Wno-long-double.)
make[2]: *** [abs.lo] Error 1
make[2]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/Users/ed/Tarballs/mpc-0.8-dev'
make: *** [all] Error 2




Once I deleted -Werror out of the makefiles...

===
All 57 tests passed
===

I don't know how you would tweak the configure to kill this -Werror for 
mac but that would do it.


Ed

Re: GCC development plan

[Ed Smith-Rowland]

Piotr Wyderski wrote:

Tobias Burnus wrote:

  

Well, for the new features in the trunk: Have a look at the release
notes for the upcoming version 4.5 at
http://gcc.gnu.org/gcc-4.5/changes.html
For C++ 0x (1x?) have also a look at
http://gcc.gnu.org/gcc-4.5/cxx0x_status.html



Yes, I know those pages pretty well, as I check  the
C++0x implementation progress every other week.
But, from the perspective of trunk, they describe what
has already been done and I'm using that features happily.

Of course I realize that there is no strict plan,
as it is an Open Source project run by volunteers.
I would like to know what is in progress or planned
/speculated to be, but failed to find that information.
The person who maintains the mentioned sites
somehow knows what is going on under the hood,
so I wonder whether that information is available
to mere mortals, and -- if yes -- then how.

  

No - there might be some (tentative) plan for some parts of the compiler
and ideas what should implemented first



That would be more than enough, but where can I find that?
I read this list rather carefully, however not much information
of that kind is disclosed here.

Best regards
Piotr Wyderski

  
I think there are three broad parts to this question: infrastructure, 
core language and library runtimes.  I tend to work on the latter and in 
that case I think all the languages are trying to fill any holes in the 
published standards for those languages.  I know at least C, C++, and 
Fortran have status pages in the manual and in Wikis describing the 
coverage with respect to the various standards and Technical Reports and 
Defect Reports in each language.  Pick a hole and start filling.


As for infrastructure I know much less.  It seems that a lot of thought 
is presented at GCC workshops.  Ideas are presented for new optimization 
passes and so on.  Also, watching the list will reveal annoyances like 
reload and other stuff.  Obviously I don't know these parts ;-) well 
enough to talk.


As a core language evolves in subsequent standards (in particular, right 
now, C++-0x is coming up) new language features must be supported 
possibly in conjunction with the corresponding runtime.  As for timing 
at least C++ and possibly Fortran track the standards as the progress 
and add features as they solidify either in an experimental mode or on a 
separate branch.  Gcc is an important part of the feedback loop into the 
wider standards world about implementation experience for new language 
and library proposals.


So basically, it's this: 1. look at the standards documents, 2. look at 
the current coverage in gcc, 3. Fill holes, 4. Don't add too much new 
stuff.  Rinse.  Repeat.


Ed

[C++-0x] Status of constexpr

[Ed Smith-Rowland]

Greetings,

I have a patch in my tree that employs the constexpr keyword in most of 
the places in the library where it is required in n3000.  This patch 
bootstraps and causes no new regressions on MacOS at least.  I still 
need test cases.


My question is this: Is constexpr in good enough shape to put this in?  
Some message seemed to suggest it wasn't finished yet.


Thanks,

Ed

Re: [RFH] A simple way to figure out the number of bits used by a long double

[Ed Smith-Rowland]

Paolo Carlini wrote:

On 02/26/2010 01:03 PM, Andreas Schwab wrote:
  

Paolo Carlini  writes:


At the moment I'm trying to cook up something fixing that count with
LDBL_MANT_DIG, but maybe there is something simpler, maybe using
preprocessor builtins?!?

  

What's wrong with LDBL_MANT_DIG?
  


Nothing Andreas, the information is all there, essentially. I was hoping
in something more "clever", and closer to the actual number, including
the exponent, etc.

Paolo.

  
Huh.  I would have *sworn* that sizeof(long double) was 10 not 16 even 
though we know it was 80 bits.


How about (in the language of numeric_limits):

bits = 1 //  sign bit
 + ::digits//  significand bits
 + log2(1 + ::max_exponent - ::min_exponent)  //  exponent bits

There are preprocessor macros for each these things IIRC if you would 
rather use those.


Another possibility: ask our Fortran brethren who support  real*4, 
real*8, real*10, real*16, etc.


Ed

Re: [RFH] A simple way to figure out the number of bits used by a long double

[Ed Smith-Rowland]

Ed Smith-Rowland wrote:

Paolo Carlini wrote:

On 02/26/2010 01:03 PM, Andreas Schwab wrote:
 

Paolo Carlini  writes:
   

At the moment I'm trying to cook up something fixing that count with
LDBL_MANT_DIG, but maybe there is something simpler, maybe using
preprocessor builtins?!?
  

What's wrong with LDBL_MANT_DIG?
  

Nothing Andreas, the information is all there, essentially. I was hoping
in something more "clever", and closer to the actual number, including
the exponent, etc.

Paolo.

  
Huh.  I would have *sworn* that sizeof(long double) was 10 not 16 even 
though we know it was 80 bits.


How about (in the language of numeric_limits):

bits = 1 //  sign bit
 + ::digits//  significand bits
 + log2(1 + ::max_exponent - ::min_exponent)  //  exponent bits

There are preprocessor macros for each these things IIRC if you would 
rather use those.


Another possibility: ask our Fortran brethren who support  real*4, 
real*8, real*10, real*16, etc.


Ed



Except you probably have that already.

C++0X constexpr implementation status

[Ed Smith-Rowland]

Greetings,

In my efforts to build C++-0X library components I've noticed that 
constexpr member variables are used in several places.  I was unable to 
implement these as intended and reverted to const accessors.


It seems like the intent is sort of a static const function except that 
it binds to a specific instance.


I looked around and it looked like some effort had taken place to 
implement constexpr in the front end.  I was wondering where this effort 
left off?  Will it be picked up in the gcc-4.5 time frame?


Thanks,

Ed.

C++-0x range for loop

[Ed Smith-Rowland]

Greetings,

I was wondering if any one was working on the C++-0x range for loop.

I found an implementation in ConceptGCC that looks like it could be 
modified.


The basic strategy was to parse the loop and essentially rewrite it as 
an old fashioned loop.
Of course concepts were used to come up with functions to get begin and 
end iterators.

We would look them up from the library (they are already in).

The parsing part worked with very little change.  I'm stuck on the 
semantics part.  In particular
I'm getting an ICE initializing an rvalue from the input container 
expression.


If no one is already doing this I might continue to try my hand at it.  
Since this is my first foray into the front end I'll b begging for help ;-).


Ed Smith-Rowland

[C++0x] Working on user-defined literals.

[Ed Smith-Rowland]

Greetings,

I'm working on user-defined literals for C++-0x.  I've gotten to the 
point where I can declare non-template operator"" and call the resulting 
function explicitly.  I'm working on getting suffixed integers and 
floats out of the preprocessor to be parsed.


Before I continue I was wondering if anyone else is working on this.

If I need to continue (check cwg_active.html#1108) I'll probably be 
asking for help.


Thanks,

Ed Smith-Rowland

[C++-0x] User-defined literals.

[Ed Smith-Rowland]

Greetings,

I am slowly working on user defined literals for C++-0x.

This is my first foray into the C++ front end and I'm stuck.

Anyway, I managed to parse things like

  long double
  operator"" _foo(long double x) { return 2.0L * x; }

The result is a normal function that I can either call like
  operator "" _foo(1.2L);
or just
  _foo(1.2L);

The problem is when I parse something like

  u"string"w

I want to generate a call to something like

std::string operator"" w(const char16_t*, size_t);

i.e. I want to build a call:

w(u"string", 6);

I have a (not nearly ready for prime time) patch attached.  My current 
problem is in parser.c cp_parser_primary_expression after the string types.


Thanks for any help you can give,

Ed


Index: gcc/cp/error.c
===
--- gcc/cp/error.c  (revision 164355)
+++ gcc/cp/error.c  (working copy)
@@ -3033,7 +3033,12 @@
pedwarn (input_location, OPT_pedantic,
 "inline namespaces "
 "only available with -std=c++0x or -std=gnu++0x");
-   break;  
+   break;
+  case CPP0X_USER_DEFINED_LITERALS:
+   pedwarn (input_location, 0,
+"user-defined literals "
+"only available with -std=c++0x or -std=gnu++0x");
+   break;
   default:
gcc_unreachable();
   }
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 164355)
+++ gcc/cp/parser.c (working copy)
@@ -3579,13 +3579,50 @@
 case CPP_STRING32:
 case CPP_WSTRING:
 case CPP_UTF8STRING:
-  /* ??? Should wide strings be allowed when parser->translate_strings_p
-is false (i.e. in attributes)?  If not, we can kill the third
-argument to cp_parser_string_literal.  */
-  return cp_parser_string_literal (parser,
-  parser->translate_strings_p,
-  true);
+  {
+   tree strl;
+   cp_token *next_token;
 
+   /* ??? Should wide strings be allowed when parser->translate_strings_p
+  is false (i.e. in attributes)?  If not, we can kill the third
+  argument to cp_parser_string_literal.  */
+   strl = cp_parser_string_literal (parser,
+parser->translate_strings_p,
+true);
+
+   next_token = cp_lexer_peek_token (parser->lexer);
+   if (next_token->type == CPP_NAME)
+ {
+   tree identifier;
+   VEC(tree,gc) *vec;
+   int len = TREE_STRING_LENGTH (strl);
+
+   identifier = cp_parser_identifier(parser);
+   if (identifier == error_mark_node)
+ return error_mark_node;
+
+   /* Build up a call to the user-defined operator  */
+   vec = make_tree_vector ();
+   VEC_safe_push (tree, gc, vec, strl);
+   VEC_safe_push (tree, gc, vec, build_int_cst (size_type_node, len));
+   identifier = perform_koenig_lookup (identifier, vec,
+   /*include_std=*/false);
+   if (identifier == error_mark_node)
+ {
+   release_tree_vector (vec);
+   error ("unable to find user-defined operator");
+   return error_mark_node;
+ }
+   identifier = finish_call_expr (identifier, &vec, false, true,
+  tf_warning_or_error);
+   release_tree_vector (vec);
+
+   return identifier;
+ }
+   else
+ return strl;
+  }
+
 case CPP_OPEN_PAREN:
   {
tree expr;
@@ -10927,6 +10964,31 @@
   cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE);
   return ansi_opname (ARRAY_REF);
 
+case CPP_STRING:
+  {
+   if (cxx_dialect == cxx98)
+ maybe_warn_cpp0x (CPP0X_USER_DEFINED_LITERALS);
+   if (TREE_STRING_LENGTH (token->u.value) > 2)
+ {
+   error ("expected empty string after % keyword");
+   return error_mark_node;
+ }
+   /* Consume the string.  */
+   cp_lexer_consume_token (parser->lexer);
+   /* Look for an identifier.  */
+   id = cp_parser_identifier (parser);
+
+   /* Look for a `('.  */
+   token = cp_lexer_peek_token (parser->lexer);
+   if (token->type != CPP_OPEN_PAREN)
+ {
+   error ("expected function declaration");
+   return error_mark_node;
+ }
+
+   return id;
+  }
+
 default:
   /* Anything else is an error.  */
   break;
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 164355)
+++ gcc/cp/cp-tree.h(working copy)
@@ -389,7 +389,9 @@
   /* defaulted and deleted functions */
   CPP0X_DEFAULTED_DELETED,
   /* inline namespaces */
-  CPP0X_INLINE_NAMESPACES
+  CPP0X_INLINE

Re: [C++-0x] User-defined literals.

[Ed Smith-Rowland]

On 09/19/2010 02:37 PM, Rodrigo Rivas wrote:

Maybe Rodrigo would be interested in collaborating on this work?
 

Sure I am! Please, let me a couple of days to re-read the C++ draft,
and check this patch.
Also, take in account that I'm in no way a GCC expert... but I'll do my best.

Also I have a little patch on my own that might use some help... But
this is for another post.

Regards.
--
Rodrigo

   


I would be delighted to collaborate.

I got over my initial hump using a more generic lookup (like the 
standard says).  I'll make another patch over the next day or two

.
I can parse strings:  "sluggo"_xyz, u"facebeef"_LL, etc.

I can parse the various char types: 'x'_foo etc.

I'm looking at (besides input on what I've got currently):

1. A warning or error if a user chooses a suffix that gcc uses.  I was 
surprised that 'w', 'q', 'i', 'j' and several others were used by gcc 
for floats.  I won't be the only one.  The standard is clear that 
implementations get first crack at these but it shouldn't be a mystery 
or a surprise when things don't work as expected.


2. Should we at least pedwarn about user not starting a suffix with an 
underscore?  Probably.  Non-underscore suffixen are reserved to the 
implementation but I think a user should be able to use one if it's not 
used by gcc though the user risks non-portability and potential but 
unlikely future breakage.


3. The big one: Getting the integer(long long) and float(long double) 
suffixes that are not used by gcc out of the preprocessor.  Then we can 
build the calls.


4.  If, for long long and long double the usual signature is not found, 
first look for a: _suffix(char*) and failing that: template 
_suffix().  So we'll need to make the lookup of these two signatures 
more complex.

Re: [C++0x] implementing forward declarations for enums

[Ed Smith-Rowland]

On 09/20/2010 09:58 AM, Rodrigo Rivas wrote:

Hello all.

This patch tries to implement the C++0x featue "Forward declarations
for enums" aka "opaque enum declarations":
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf

Please note that this is a WIP, and as such lacks formatting,
comments, testcases, etc.

Except for the things noted below, I think it works pretty well.

TODOs
1
A enum declaration should fail if adds a list of constants and it
already have one. I check it with "TYPE_VALUES (type)", but this is
incorrect because an empty list will not be seen.
So, the current patch will accept incorrect code like:
enum class Foo { };
enum class Foo { A, B, C};
I think that a new flag is needed for ENUMERAL_TYPE, but I don't know which one.

2
I am calling "finish_enum" several types, for each of the opaque
declarations until it gets a list of constants. It doesn't seem to
cause problems except with the debug information. With default flags
and everything, gdb sees only the first declaration:
enum class Foo;
enum class Foo {A, B, C}
Foo f;

(gdb) ptype f;
enum Foo {}

I don't see an easy way to solve it...

3
I don't like very much the added parameter to the "start_enum"
function, but I don't see how to do it without breaking existing code.

Comments are most welcomed.

Regards.
Rodrigo
   


I did a very cursory look at the patch.

I had to initialize the variable nested_being_defined to get it to 
compile (possible uninitialized warning).  I initialized it to false.

I added some test cases mostly from the paper.

make check is still running.  I know I don't have the deja-gnu error 
trapping right so there will be FAILs that shouldn't be there.


I'll look in greater detail at your other points tonight.

It looks like the first two are related.  What does an enum look like in 
tree?  Maybe the tree for enum could have a has_definition flag.
Set it to -1 on the first declaration.  Subsequent declarations would 
know not to finish_enum.  Set it to 1 on seeing the definition.  
subsequent definitions would fail.


Ed





Index: gcc/testsuite/g++.dg/cpp0x/enum_decl1.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum_decl1.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum_decl1.C (revision 0)
@@ -0,0 +1,46 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++0x" }
+
+//  Test opaque enum declarations (pre-declared enumerations).
+//  Basic tests of declaration, definition and access.
+
+// Predeclare...
+
+enum E : short;
+
+enum class G : short;
+
+enum class H;
+
+// Redeclare...
+
+enum E : short;
+
+enum class G : short;
+
+enum class H;
+
+enum class H : int;
+
+// Define...
+
+enum E : short
+{
+  face = 0x0cab,
+  beef = 0x0bee
+};
+
+enum class H
+{
+  thing1,
+  thing2
+};
+
+// Use...
+
+void
+test1()
+{
+  short e = face;
+  H h = H::thing1;
+}
Index: gcc/testsuite/g++.dg/cpp0x/enum_decl2.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum_decl2.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum_decl2.C (revision 0)
@@ -0,0 +1,10 @@
+// { dg-do compile }
+
+//  Test opaque enum declarations (pre-declared enumerations).
+//  Predeclared enums should fail in C++98.
+
+enum E : short; // { dg-warning "scoped enums only available with -std=c++0x 
or -std=gnu++0x" } { dg-error "" }
+
+enum class G : short; // { dg-warning "scoped enums only available with 
-std=c++0x or -std=gnu++0x" } { dg-error "" }
+
+enum class H; // { dg-warning "scoped enums only available with -std=c++0x or 
-std=gnu++0x" } { dg-error "" }
Index: gcc/testsuite/g++.dg/cpp0x/enum_decl3.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum_decl3.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum_decl3.C (revision 0)
@@ -0,0 +1,18 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++0x" }
+
+//  Test opaque enum declarations (pre-declared enumerations).
+//  Test declaration of nested enumerations and scoped definition.
+
+struct S
+{
+  enum E : int;
+  E e;
+};
+
+enum S::E : int
+{
+  A,
+  B,
+  C
+};
Index: gcc/testsuite/g++.dg/cpp0x/enum_decl4.C
===
--- gcc/testsuite/g++.dg/cpp0x/enum_decl4.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/enum_decl4.C (revision 0)
@@ -0,0 +1,40 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++0x" }
+
+//  Test opaque enum declarations (pre-declared enumerations).
+//  You still need the full definition bfore use.
+
+// Predeclare...
+
+enum E : short;
+
+enum class H;
+
+// Redeclare...
+
+enum E : short;
+
+enum class H;
+
+// Use...
+
+void
+test1()
+{
+  short e = face;  // { dg-warning "was not declared in this scope" }
+  H h = H::thing1; // { dg-warning "is not a member of" }
+}
+
+// Define...
+
+enum E : short
+{
+  face = 0x0cab,
+  beef = 0x0bee
+};
+
+enum class H
+{
+  thing1,
+  thing2
+};
Index: gcc/cp/decl.c

Re: [C++0x] implementing forward declarations for enums

[Ed Smith-Rowland]

On 09/21/2010 07:05 PM, Rodrigo Rivas wrote:

I had to initialize the variable nested_being_defined to get it to compile
(possible uninitialized warning).  I initialized it to false.
 

Ok, actually it is never used uninitialized, but let's get rid of the warning.
   
I saw that it was never used uninitialized and was surprised gcc wasn't 
able to diagnose that.
My bootstrap failed because of -Werror which is turned on by default I 
guess.
   

It looks like the first two are related.  What does an enum look like in
tree?  Maybe the tree for enum could have a has_definition flag.
 

As far as I know it is a "tree_type". I was thinking of using
lang_flag_0 or similar, but I'm unsure if they are used for any other
purpose, or if there is a protocol to assign them...
   
I saw the flag situation after I sent my message.  There must be a 
"Keeper of the Sacred Tree Flag Set" somewhere.
Also, my scheme of flagging on first declaration and also flagging 
definition would consume two flags.
I get the idea the real estate is at a premium and consuming flags could 
be a problem.
Perhaps there is a context flag saying "You're inside braces" or 
something so we wouldn't need the second flag.


I'll try to figure out what is done with classes, unions, etc. in this 
regard.  Basically this is the same situation.

Rodrigo

   

Ed

Re: [C++-0x] User-defined literals.

[Ed Smith-Rowland]

On 09/21/2010 06:47 PM, Rodrigo Rivas wrote:

I'm holding out for rolling back the lexer in some way that won't break 
everything and emitting the (unrecognized by cpp ) suffix as a separate 
identifier token.  I'm thinking the cp_lexer_* routines or maybe a new one in 
parser.c would be worth trying.  Then the code I have now would just work 
(except I would still need enhanced lookup rules as discussed earlier).  It 
would be nice to have all types on the same page too.
 

Hmmm, you indend to break the user-defined integer/float into two
tokens: the number and the suffix. I don't know... it may cause quite
some unexpected problems. Note that the draft defines a
user-defined-literal as *one* token but you want to read it as *two*
tokens.
That would make ill-formed code parseable, for example:
int x = 10 /* whatever */ _foo;

On second thought, this already happens with strings and chars:
"xxx" /**/ _bar;
is parsed fine with your current patch, but I believe it should not.

Rodrigo.

   

I'm coming around to your idea.  I'm giving up on tokenizing tricks.

We got "lucky" with chars and strings because there was no pre-existing 
significance to a suffix in those cases.

I haven't tried it but I think this would "pass":
"Hello, World!"   _foo;
with space between the string and the suffix.

I know this passes but shouldn't:

   operator ""E(long double);
with no space between the string and the 'E'.

Maybe once I get numbers working I'll turn to those issues.

Ed

Re: [C++-0x] User-defined literals.

[Ed Smith-Rowland]

This is to get a paper trail started.

TODO: Find out if/what LTO issues there may be with user-defined literals.

Ed

Re: Merging Apple's Objective-C 2.0 compiler changes

[Ed Smith-Rowland]

Nicola, Iain, Mike,

It would be great if you all could update 
http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and related with all the 
great work that has gone into Objective-C++ recently.


Those of us hoping to play with the new Objective-C want to know. ;-)

Thank you,

Ed

Possible accept wrong code in C++?

[Ed Smith-Rowland]

All,

I have a template class:

template < class Datum, unsigned long Dim >
class DataGrid
{
   ...
public:
   ...
   std::ostream &  write( std::ostream & output ) const;
   ...
};

I have a non-member operator overload:

On GCC-3.4 Cygwin I needed:

template < class Datum, unsigned long Dim >
inline std::ostream &  operator<<( std::ostream & output, const 
DataGrid & data_grid )

{
   return  data_grid.write( output );
}

On GCC-4.0 MacOSX I was able to get by with this:

inline std::ostream &  operator<<( std::ostream & output, const DataGrid 
& data_grid )

{
   return  data_grid.write( output );
}

I actually think that 3.4 is right!!!
Am I wrong?

I'll try mainline and 4.1 when I get back home.

Ed Smith-Rowland

Re: Possible accept wrong code in C++?

[Ed Smith-Rowland]

Smith-Rowland, Edward M (Contractor) wrote:


All,

 


I have a template class:

 


template < class Datum, unsigned long Dim >

class DataGrid

{

...

public:

...

std::ostream &  write( std::ostream & output ) const;

...

};

 


I have a non-member operator overload:

 


On GCC-4.0 MacOSX I was able to get by with this:

 

inline std::ostream &  operator<<( std::ostream & output, const 
DataGrid & data_grid )


{

return  data_grid.write( output );

}

On GCC-3.4 Cygwin I needed:

 


template < class Datum, unsigned long Dim >

inline std::ostream &  operator<<( std::ostream & output, const 
DataGrid & data_grid )


{

return  data_grid.write( output );

}

 


I actually think that 3.4 is right!!!

Am I wrong?

 


I'll try mainline and 4.1 when I get back home.

 


Ed Smith-Rowland



It turns out I was using some old 4.1 snapshot rather than 4.0 when this 
strange code passed.


The operator overload without template stuff fails (correctly) for the 
latest 4.1 snap, 4.0.2, etc.


Nothing to see here, move along.

Ed

Re: GNU Pascal branch

[Ed Smith-Rowland]

All,

FWIW, I would like to add my support for creating a branch for gpc with 
the eventual goal
of integrating Pascal into mainline.  I would bootstrap and test this 
branch, report bugs and

do my best to help with solutions although I'm new at this.

I think both projects would benefit.  I'll venture some predictions:

GCC
1. Another language would test the middle and back ends more and expose 
more bugs.
   There would be the process, structure, and motivation to fix them 
because gpascal is integrated.
2. I know of one person from the gpc world who participates in gcc and 
understands the gcc-4+ internals.

   I'm sure more would follow.
3. It would be cool to have more languages!
   
--enable-languages=c,c++,java,objc,obj-c++,fortran,treelang,ada,pascal,   
Mwahahahah!!!
4. There are multi-language Pascal-C, etc systems that GCC would be left 
out of without gpascal.


GPC
1. The later versions of gcc are getting faster.  Moving gpc off of gcc-3
   and into gcc-4 would speed things up.  GCC-3.4.6 is the end of the 
line for GCC-3.

2. By targeting integration rather than proximity, all the recent work in
   getting gpascal to work with gcc-4 would be less likely to bitrot.
3. GPC would get much wider exposure.  It would probably eventually ship
   along with the rest of gcc in OS distributions including *ahem* MacOSX.
4. I've seen questions on the gpc mailing list about the availability of 
OpenMP for Pascal.
   I don't think OpenMP treats Pascal but gcc has OpenMP integrated 
into the C, C++,

   and Fortran frontends and has a common OMP runtime.
   If OMP was wanted as an extension or became part of OpenMP then your 
best bet is GCC.

5. I believe that more people would join the GPC maintenance effort.

I get the sense that there are wounds from old battles.  Based on the 
replies I believe that many of the complaints
(perceived and/or real): poor response to bug reports, second class 
citizen feelings - would fall by the wayside if

a branch with the goal of full integration were initiated.

This would require that friendly dialog would ensue and that new people 
are eased
into a different culture in a welcoming manner.  This would require a 
change in workflow

and project structure for gpascal.  But I think it is worth it.

I really hope that these issues and others can be resolved for the 
benefit of all.


Peace,
Ed Smith-Rowland

Re: 3 byte variables [feature request]

[Ed Smith-Rowland]

On 06/05/2013 10:43 AM, kuldeep dhaka wrote:

Hello,

while working on a program i faced a problem.
i need only 20 bit , and having a 32 bit only waste more memory(12
byte), 24bit would much be better.
i need a uint24_t variable but gcc dont support it so i have to start
with uint32_t.
it would be very nice if gcc support such variables.
i made a little program and found that gcc (on i686) returned error.

http://embeddedgurus.com/stack-overflow/2009/06/three-byte-integers/

--
Kuldeep Singh Dhaka
Sakul
+91-8791676237
kuldeepdha...@gmail.com
Programmer, Open Source, Web Developer, System Administrator,
Entrepreneur, Animal Lover, Student, Reverse Engineer, Embedded
System, Learning.

Bitcoins Accepted.
My GnuPG Public Key
Fork Me

Even if gcc had such a type I bet they would get aligned to 4-bytes on 
most any target.


My guess is his won't be a high priority for folks.  You could look at 
how types are implemented in gcc, write a patch, make a case and see if 
you can get it in.


Ed

[C++14] Admit C++ keywords as literal suffixes.

[Ed Smith-Rowland]

I understand that the literal operators for complex numbers for C++14 
faltered at least in part because of the perceived ugliness of the float 
operator:


constexpr complex
operator"" i_f();  //  fugly

The obvious choice
constexpr complex
operator"" if();

failed because 'if' is a keyword.  The 'if' keyword can never be exposed 
in this context either by usage in a literal or by explicit call.


Allowing keywords as literal operator suffixes turns out to be a 6-liner 
if gcc.  I actually think *disallowing* them is a bit of a bug.  (Not 
sure if it was me or the standard).


I don't know if that's the wording but I just wanted to offer a working 
implementation of the idea.


Ed

Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 200158)
+++ gcc/cp/parser.c (working copy)
@@ -12359,6 +12358,13 @@
  return cp_literal_operator_id (name);
}
}
+  else if (token->type == CPP_KEYWORD)
+   {
+ id = ridpointers [(int) token->keyword];
+ cp_lexer_consume_token (parser->lexer);
+ const char *name = IDENTIFIER_POINTER (id);
+ return cp_literal_operator_id (name);
+   }
   else
{
  error ("expected suffix identifier");

Way to tell in libcpp if something is a macro...

[Ed Smith-Rowland]

Greetings,

I have a situation where I would like to detect if a string is a 
currently defined macro.


Something like a

  bool cpp_is_macro(const unsigned char *);

would be great.

Or perhaps I could construct something from the string and test that.

If something like this doesn't exist does anyone have some pointers on 
how to make one for libcpp.


Thanks.

Remove the __GXX_EXPERIMENTAL_CXX0X__?

[Ed Smith-Rowland]

While thinking about C++ n3694 feature test macros I noticed we still define 
__GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c.
We got rid of all uses of it in libstdc++.
I propose we get rid of it here too.
User's shouldn't be relying on it.  No?

OTOH, it may have been a proxy for __cplusplus for users for a good while.  
People may still be using it even if the library no longer uses it.

What do folks think?

[C++11] PR54413 Option for turning off compiler extensions for numeric literals.

[Ed Smith-Rowland]

I sent this to the wrong list originally, apologies to those who get it 
twice.


There is a request to be able to turn off interpretation of several 
suffixes for gcc extension numeric literals to make way for C++-1Y or 
various std libraries to claim several suffixes currently used for gnu 
extensions.


This patch interprets the suffixes according to the current extension 
rules by default.  But if -std=c++1y is used as the C++ standard then 
the flags are off by default allowing use as C+11 user-defined literals.


I would like to get this into 4.8 if I can.

It passes on x86_64 linux.

Regards,
Ed


libcpp

2012-11-05  Ed Smith-Rowland  <3dw...@verizon.net>

PR c++/54413
* include/cpplib.h (cpp_interpret_float_suffix): Add cpp_reader* arg.
(cpp_interpret_int_suffix): Add cpp_reader* arg.
* init.c (cpp_create_reader): Iitialize new flags.
* expr.c (interpret_float_suffix): Use new flags.
(cpp_interpret_float_suffix): Add cpp_reader* arg.
(interpret_int_suffix): Use new flags.
(cpp_interpret_int_suffix): Add cpp_reader* arg.
(cpp_classify_number): Adjust calls to interpret_x_suffix.


gcc/c-family

2012-11-05  Ed Smith-Rowland  <3dw...@verizon.net>

PR c++/54413
* c-opts.c (c_common_handle_option): Set new flags.
* c.opt: Describe new flags.


gcc/cp

2012-11-05  Ed Smith-Rowland  <3dw...@verizon.net>

PR c++/54413
* decl.c (grokfndecl): Adjust calls to interpret_x_suffix.


gcc/testsuite

2012-11-05  Ed Smith-Rowland  <3dw...@verizon.net>

PR c++/54413
* g++.dg/cpp0x/fno-fixed-point-literals.C: New.
* g++.dg/cpp0x/fno-imaginary-literals.C: New.
* g++.dg/cpp0x/fno-machine-defined-literals.C: New.
* g++.dg/cpp0x/ffixed-point-literals.C: New.
* g++.dg/cpp0x/fimaginary-literals.C: New.
* g++.dg/cpp0x/fmachine-defined-literals.C: New.


Index: libcpp/include/cpplib.h
===
--- libcpp/include/cpplib.h (revision 192897)
+++ libcpp/include/cpplib.h (working copy)
@@ -431,6 +431,18 @@
  ud-suffix which does not beging with an underscore.  */
   unsigned char warn_literal_suffix;
 
+  /* Nonzero means interpret imaginary number suffix as an imaginary number
+ literal.  */
+  unsigned char imaginary_literals;
+
+  /* Nonzero means interpret fixed-point number suffix as a fixed-point number
+ literal.  */
+  unsigned char fixed_point_literals;
+
+  /* Nonzero means interpret fixed-point number suffix as amachine-defined
+ number literal.  */
+  unsigned char machine_defined_literals;
+
   /* Holds the name of the target (execution) character set.  */
   const char *narrow_charset;
 
@@ -854,10 +866,12 @@
 const char **, source_location);
 
 /* Return the classification flags for a float suffix.  */
-extern unsigned int cpp_interpret_float_suffix (const char *, size_t);
+extern unsigned int cpp_interpret_float_suffix (cpp_reader *, const char *,
+   size_t);
 
 /* Return the classification flags for an int suffix.  */
-extern unsigned int cpp_interpret_int_suffix (const char *, size_t);
+extern unsigned int cpp_interpret_int_suffix (cpp_reader *, const char *,
+ size_t);
 
 /* Evaluate a token classified as category CPP_N_INTEGER.  */
 extern cpp_num cpp_interpret_integer (cpp_reader *, const cpp_token *,
Index: libcpp/init.c
===
--- libcpp/init.c   (revision 192897)
+++ libcpp/init.c   (working copy)
@@ -182,6 +182,9 @@
   CPP_OPTION (pfile, track_macro_expansion) = 2;
   CPP_OPTION (pfile, warn_normalize) = normalized_C;
   CPP_OPTION (pfile, warn_literal_suffix) = 1;
+  CPP_OPTION (pfile, imaginary_literals) = 1;
+  CPP_OPTION (pfile, fixed_point_literals) = 1;
+  CPP_OPTION (pfile, machine_defined_literals) = 1;
 
   /* Default CPP arithmetic to something sensible for the host for the
  benefit of dumb users like fix-header.  */
Index: libcpp/expr.c
===
--- libcpp/expr.c   (revision 192897)
+++ libcpp/expr.c   (working copy)
@@ -61,8 +61,8 @@
 static cpp_num parse_defined (cpp_reader *);
 static cpp_num eval_token (cpp_reader *, const cpp_token *, source_location);
 static struct op *reduce (cpp_reader *, struct op *, enum cpp_ttype);
-static unsigned int interpret_float_suffix (const uchar *, size_t);
-static unsigned int interpret_int_suffix (const uchar *, size_t);
+static unsigned int interpret_float_suffix (cpp_reader *, const uchar *, 
size_t);
+static unsigned int interpret_int_suffix (cpp_reader *, const uchar *, size_t);
 static void check_promotion (cpp_reader *, const struct op *);
 
 /* Token type abuse to create unary plus and minus operators.  */
@@ -87,7

Re: Issue with c++11 header random.h

[Ed Smith-Rowland]

On 12/03/2012 11:29 AM, Paolo Carlini wrote:

Hi,

On 12/03/2012 04:54 PM, Nolen, Steven D wrote:
In the c++11 headers for the random number generation (random.h), the 
function "discard" for the linear_congruential has been implemented 
in a very inefficient manner.
As I mentioned when we optimized a while ago the discard member 
function for the statistically much more solid mersenne_twister 
engine, most of the discard are still just trivial implementations of 
the specs, that is rather well know. On the other hand, we didn't take 
code from Boost for our implementation and I don't think we are 
starting now. Thus, if you want to see progress on this specific 
discard, I would recommend either contributing a patch, if the issue 
is simple enough for you to handle, or filing an appropriate Bugzilla 
entry with a description of the optimization, then somebody will 
contribute an implementation.


Thanks!
Paolo.


Greetings,

Thank you for your concern about the random facility.

A link to a reference paper or two would help if you don't want to/can't 
contribute a patch.


Thanks,
Ed

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Ed Smith-Rowland via Gcc]

On 11/26/20 6:50 PM, Jonathan Wakely via Gcc wrote:

I've touched on the subject a few times, e.g.
https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html

Libstdc++ code is indented by 2 columns for the enclosing namespace,
usually another two for being in a template, and is full of __
prefixes for reserved names. On top of that, modern C++ declarations
are *noisy* (template head, requires-clause, noexcept-specifier, often
'constexpr' or 'inline' and 'explicit', and maybe some attributes.

All that gets hard to fit in 80 columns without compromising
readability with line breaks in unnatural places.

Does anybody object to raising the line length for libstdc++ code
(not the rest of GCC) to 100 columns?

Please read my replies in the thread linked above before telling me
that the code should be split up into smaller functions to avoid deep
nesting. The function I pointed to cannot easily be split up without
making the code slower to compile and potentially slower to run:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/stl_algobase.h;h=a2fd306e6d0cca579b510148ba1a7089e2b2f3a2;hb=HEAD#l1499 




+1