Re: __LDBL_MAX__ exceeds range of 'long double'

[Jonathan Wakely]

On Mon, Feb 21, 2005 at 09:14:22PM -0800, James E Wilson wrote:

> Jonathan Wakely wrote:
> >$ gcc4x -c bug.c -pedantic -save-temps
> >bug.c: In function 'main':
> >bug.c:1: error: floating constant exceeds range of 'long double'
> 
> This is easy enough to explain.  Grepping for the message shows that it 
> is printed from c-lex.c, and is only printed when -pedantic. 
> -save-temps means we run cc1 twice, once to produce the .i file, and 
> once to read the .i file.  So the problem is either writing the .i file 
> or reading the .i file.
> 
> Looking further, I noticed that FreeBSD sets the rounding mode to 
> 53-bits.  real.c knows this, and computes values appropriately, i.e. 
> 96-bit values with 53-bits of fraction.  Unfortunately, this value isn't 
> getting propagated properly to the C preprocessor when using 
> -save-temps/-E, and this problem exists because 
> init_adjust_machine_modes is run in the wrong place.  It is run from 
> backend_init, but it needs to be run always, as we need it to compute 
> the FP predefined macros correctly.
> 
> The value really is wrong, even though it is the same as gcc-3.4.  It 
> has 11 too many bits of fraction.
> 
> Targets using paired-double long double formats are probably also wrong. 
> Anything that overrides the normal IEEE FP formats will be wrong.
> 
> Attached is a mostly untested patch to fix this.  It works for your 
> testcase.  And it now prints a different correct value of __LDBL_MAX__ 
> in the .i file.

Sorry for the late reply. It does indeed fix the problem I saw with 4.0
on FreeBSD, but I'm now seeing this with 3.4.4 20050228 too, so I think
it's a regression introduced in the last 6 weeks or so.

Is the same fix safe to apply to 3.4?

I got no regressions testing on x86/FreeBSD a few days ago. I'm in the
process of updating and re-testing current 3.4.

jon

> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

> 2005-02-21  James E Wilson  <[EMAIL PROTECTED]>
> 
>   * toplev.c (backend_init): Don't call init_adjust_machine_modes here.
>   (do_compile): Do call it here.
> 
> Index: toplev.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/toplev.c,v
> retrieving revision 1.942
> diff -p -p -r1.942 toplev.c
> *** toplev.c  12 Feb 2005 00:26:52 -  1.942
> --- toplev.c  22 Feb 2005 04:58:04 -
> *** process_options (void)
> *** 1954,1961 
>   static void
>   backend_init (void)
>   {
> -   init_adjust_machine_modes ();
> - 
> init_emit_once (debug_info_level == DINFO_LEVEL_NORMAL
> || debug_info_level == DINFO_LEVEL_VERBOSE
>   #ifdef VMS_DEBUGGING_INFO
> --- 1954,1959 
> *** do_compile (void)
> *** 2092,2097 
> --- 2090,2100 
> /* Don't do any more if an error has already occurred.  */
> if (!errorcount)
>   {
> +   /* This must be run always, because it is needed to compute the FP
> +  predefined macros, such as __LDBL_MAX__, for targets using non
> +  default FP formats.  */
> +   init_adjust_machine_modes ();
> + 
> /* Set up the back-end if requested.  */
> if (!no_backend)
>   backend_init ();

Re: HELP!!!!

[Jonathan Wakely]

On Wed, Mar 02, 2005 at 04:36:26PM -0500, Jesus Christ wrote:

> Hello,
> My name is Caleb Statser and I have recently checked out the book "C++
> For Dummies", fourth edition.  It is supposed to come with a CD that
> contains all of the source code from the book along with a copy of
> "GNU C++", but alas, the CD was no where to be found, at least not in
> the book that I checked out.  I have attempted without succes to
> download a copy of it off of the internet but I will openly admit,
> even downloading it is too complex for me.  I guess i am just getting
> bogged down in all fo the Zip files and strange extensions.  I would
> greatly appreciate it if you would send me a direct link to somewhere
> where the program is availabe to a person who dosen't yet know what
> they are doing.

Hi Caleb,

this list is for development of GCC, your question would be more
appropriate on [EMAIL PROTECTED]

Assuming you want a compiler to run on windows, try this:
http://ems.calumet.purdue.edu/mcss/kraftrl/cs302/mingw-install.html

That page starts off by installing the compiler, then recommends
installing a development environment called Quincy:
http://www.alstevens.com/quincy2002/index.html

Qunicy is a development environment that works with MinGW (a version of
the GNU C++ compiler for windows). The Quincy site includes instructions
on downloading and installing MinGW, which you can get here:

Another set of step-by-step instructions here:
http://members.shaw.ca/CompSci30S/Chapter%202/Ch02pg01.html
http://members.shaw.ca/CompSci30S/Chapter%202/Ch02pg02.html

N.B. the Quincy FTP site doesn't seem to be responding right now but
that's probably temporary, there's a copy of the download file here:
http://www.kishwaukeecollege.edu/faculty/sgrever/cis150/quincy.html
but I have no idea if that copy is safe, it could have been modified.
Use it at your own risk.

You might want to try a book called "You Can Do It" by Francis
Glassborrow, which comes with a CD that includes Quincy and MinGW.
I've not looked at "C++ For Dummies" but Francis's book is very good.

jon

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.

[Jonathan Wakely]

On Fri, Mar 04, 2005 at 03:51:42PM +0100, Karel Gardas wrote:

> I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
> not. I have for example abstract base class like:
> 
> class Foo
> {
> public:
> virtual unsigned short
> iiop_version() const = 0;
> };
> 
> and when I compile it, GCC emits warning from subject, although this class
> is really abstract and will never be instantiated. It's quite easy to add
> virtual dtor there, but I'm reluctant to do so, since IMHO GCC should
> check if the class is abstract or not, so I would like to ask if I should
> fill a bugreport or correct my code.

If it's an Abstract Base Class and you intend to use it through a
pointer-to-base (or reference-to-base) then it's important that you add
a virtual dtor. 

Whether it is abstract or not has nothing to do with it - if you will
ever delete a derived object with a static type of the base class then
the behaviour is undefined if the base class does not have a virtual
dtor.

e.g. this is undefined behaviour:

class Base {};
class Derived : public Base {};

Base* p = new Derived;
delete p;

To quote the Holy Standard:

5.3.5 [expr.delete]

-3- In the first alternative (delete object), if the static type of
the operand is different from its dynamic type, the static type
shall be a base class of the operand's dynamic type and the static
type shall have a virtual destructor or the behavior is undefined.
In the second alternative (delete array) if the dynamic type of the
object to be deleted differs from its static type, the behavior is
undefined.

I suggest you add "virtual ~Foo() {}" to your class.

jon


-- 
"Sell your cleverness and buy bewilderment:
 Cleverness is mere opinion, bewilderment is intuition."
- Jalal-uddin Rumi

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.

[Jonathan Wakely]

On Sat, Mar 05, 2005 at 09:00:38AM -0500, Michael N. Moran wrote:

> In embedded system work, and I'm sure in other circumstances,
> it is the case that "placement new" is the norm and destructors
> invoked explicitly (never on an abstract reference,) and the
> delete operator goes unused.

I should never have just said "add a virtual dtor" without qualification
:)

I assume in specialised domains where you have to know what you're
doing you will also know whether a virtual dtor is appropriate (and
can use -Wno-non-virtual-dtor to suppress the warning). If you're not
sure who might use the class and what they'll do, you have to be more
careful.

I was too quick to suggest adding the virtual dtor, clear documentation
that says "don't use delete with this type" might do the job equally
well - the important thing is to prevent the problem happening.

jon

-- 
Message terminated with signal 11, SIGFAULT

Re: Deprecating min/max extension in C++

[Jonathan Wakely]

On Tue, Mar 08, 2005 at 02:06:48PM +0100, Giovanni Bajo wrote:

> Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 
> > IMO, if these are C++-only, it's relatively easy to deprecate these
> > extension -- but I'd like to hear from Jason and Nathan, and also the
> > user community before we do that.  Of all the extensions we've had, this
> > one really hasn't been that problematic.
> 
> I would prefer them to stay. My reasons:
> 
> 1) std::min() and std::max() are not exact replacements. For instance, you
> cannot do std::min(3, 4.0f) because the arguments are of different type.
> Also, you cannot use reference to non-const types as arguments. The min/max
> exensions do not suffer from these problems (I consider the former very
> problematic, and the latter just annoying).

I was about to reply making the same point about template argument
deduction.


Whether or not the extensions get deprecated, shouldn't the docs for
them at least mention std::min and std::max, rather than only referring
to the infamous, flawed macros?

* gcc/doc/extend.texi: Mention std::min and std::max in docs for
min/max operators.

Patch OK for mainline?

jon

-- 
"In theory, practice and theory are the same,
 but in practice they are different."
- Larry McVoy
Index: gcc/doc/extend.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.241
diff -u -p -b -B -r1.241 extend.texi
--- gcc/doc/extend.texi 25 Feb 2005 18:29:28 -  1.241
+++ gcc/doc/extend.texi 8 Mar 2005 13:00:45 -
@@ -9157,6 +9157,10 @@ Since @code{?} are built 
 handle expressions with side-effects;  @[EMAIL PROTECTED] min = i++ }) also correctly handle expressions with side-effects
+e.g. @[EMAIL PROTECTED] min = std::min(i++, j++);}}
+
 @node Volatiles
 @section When is a Volatile Object Accessed?
 @cindex accessing volatiles

Re: C++ [RFC] taking address of a static const data member

[Jonathan Wakely]

On Fri, Mar 11, 2005 at 11:49:22AM -0800, Fariborz Jahanian wrote:

> Thanks Andrew. Yes, standard actually mentions this that I missed.

It's also doc'd here:
http://gcc.gnu.org/onlinedocs/gcc/Static-Definitions.html#Static-Definitions

jon

Re: Why aren't assignment operators inherited automatically?

[Jonathan Wakely]

On Wed, Mar 16, 2005 at 10:45:16AM +0200, Topi Maenpaa wrote:

> In short, anything inherited from the base class can be used as expected, 
> except the assignment operator. What's the deal? I'm doing this on Mandrake 
> 10.1, gcc 3.4.1, if that matters.

This question is about C++, not the development of GCC, so would be
better suited somewhere like comp.lang.c++

Basically, G++ does what the standard requires.  The assignment operator
is special, if you don't declare one the compiler does so implicitly and
the implicit operator= hides the inherited one.

See a good C++ reference for "name hiding".

jon

Re: Questions about trampolines

[Jonathan Wakely]

On Wed, Mar 16, 2005 at 10:51:55AM -0400, Manuel Baez wrote:

> Please some moderator, remove me from this list, I'cant do it

Look at the "List-Unsubscribe" header.

Alternatively you could have tried going to the GCC web site and
clicking on "mailing lists", where you'll find a form to unsubscribe.

jon

Re: Compiler chokes on a simple template - why?

[Jonathan Wakely]

On Thu, Mar 17, 2005 at 10:33:54AM +0200, Topi Maenpaa wrote:

> Hi,
> 
> Here is a snippet that does not compile with gcc 3.4.1 (on Mandrake 10.1).
> 
> ---
> template  class A
> {
> public:
>   template  void test(T value) {}
> };
> 
> template  void test2(A& a, T val)
> {
>   a.test(val);

This needs to be:

   a.template test(val);

> }
> 
> int main()
> {
>   A a;
>   a.test(1); //works fine
> }
> ---

> 
> $ g++ -o test test.cc
> test.cc: In function `void test2(A&, T)':
> test.cc:9: error: expected primary-expression before "int"
> test.cc:9: error: expected `;' before "int"

Because test2 is a template it doesn't know what A is (in the general
case) so you need to tell the compiler that a.test is a function template,
otherwise it is parsed as a member variable, giving "a.test less-than int",
which doesn't make sense.

> The funny thing is that if I change the name of the "test2" function to 
> "test", everything is OK. The compiler complains only if the functions have 
> different names. Why does the name matter?

That I'm not sure about ...
I would have expected it to fail with the same error when the function
is called "test" - but I'd be wrong apparently.

> The code compiles if "test2" is not a template function.

Because in that case the compiler knows the full definition of A and
knows that a.test refers to a function template, not a member variable
(for instance).

>  Furthermore, calling 
> A::test directly from main rather than through the template function works 
> fine.

Again, in that context the compiler knows that a.test is a function
template.

> I don't know if this is really a compiler thing, but it's hard to imagine the 
> standard would impose such behavior.

Yes, it's ugly. No, it's not a bug. It's required by the standard  :-(

jon

-- 
"I find television very educating. Every time somebody turns on the set, 
 I go into the other room and read a book."
- Groucho Marx

Re: Compiler chokes on a simple template - why?

[Jonathan Wakely]

On Thu, Mar 17, 2005 at 11:03:53AM +0100, Giovanni Bajo wrote:

> Topi Maenpaa <[EMAIL PROTECTED]> wrote:
> 
> > The funny thing is that if I change the name of the "test2" function
> > to "test", everything is OK. The compiler complains only if the
> > functions have different names. Why does the name matter?
> 
> This is surely a bug. Would you please file a bug report about this?

That's what I thought - comeau seems to have the same bug btw.

jon

-- 
"You can lead a horticulture but you can't make her think."
- Dorothy Parker

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 11:47:56AM +0200, tbp wrote:

> Hello,
> 
> i'm a bit puzzled by the behaviour of gcc4 (old 4.0 & recent 4.1
> snapshots) regarding how template specialization should be qualified
> wrt namespace:
[snip]
> Other compilers (gcc 3.4.x, msvc2k3, icc8.1) don't whine.

GCC 3.4 *does* whine, and I think Intel will in strict mode.

jon

-- 
"The whole problem with the world is that fools and fanatics are always
 so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 12:15:07PM +0200, tbp wrote:

> On Apr 4, 2005 11:54 AM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> > > Am i missing something obvious?
> > well, not 'obvious', but that is what [14.7.3]/2 says.
> I especially don't quite get why specialization have to be defined
> that way when non specialized version don't have to, ie that is legit:
> namespace dummy {
>   struct foo {
>   template  void f();
>   };
> } 
> template void dummy::foo::f() { }

That's not an explicit specialisation, so the same rules don't apply.
That's just a definition of the primary template.

[14.7.3]/2 says that the *declaration* of an explicit specialisation
must appear in the same namespace. The *definition* can appear in an
enclosing namespace (as with your example above,) so you can do this:

namespace dummy {
struct foo {
template  void f() {}
};
template<> void foo::f<666>();// declare specialisation
}
template<> void dummy::foo::f<666>() {}   // define specialisation

Hope that helps,

jon

-- 
Prediction is very difficult, especially about the future.
- Niels Bohr

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 01:03:19PM +0200, tbp wrote:

> On Apr 4, 2005 12:50 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > GCC 3.4 *does* whine, and I think Intel will in strict mode.
> Can't get neither gcc 3.4.1 to whine about it (-Wall) nor icc 8.1 with
> the highest warning level enabled.

Oh, sorry! the 3.4.4 20050321 (prerelease) I tried does error, and
Comeau in strict mode does, so I thought Intel might too.

Apologies,

jon

-- 
"Neither a man nor a crowd nor a nation can be trusted to act humanely, or
 to think sanely, under the influence of a great fear."
- Bertrand Russell

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 01:08:37PM +0200, tbp wrote:

> On Apr 4, 2005 1:04 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > Hope that helps,
> Yes, thanks and for once gcc warning was explicit enough (with a hint
> about namespace) for me to fix it.

:-)
It might be even better if the error indicated that only the definition
needs to be in the same namespace. 

What I mean is that GCC rejects the following code saying:

test.cc:7: error: specialization of `template void dummy::foo::f()' in 
different namespace
test.cc:3: error:   from definition of `template void dummy::foo::f()'

but actually the specialisation and definition are both in the global
namespace:

namespace dummy {
struct foo {
template  void f();
};
}
template  void dummy::foo::f() {}
template<> void dummy::foo::f<666>() {}

The error is that the specialisation is in a different namespace from
the declaration, not the definitionn.

Does anyone agree? Should I file a PR?

jon

-- 
"Reality is that which, when you stop believing in it, doesn't go away."
- Phillip K. Dick

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 01:02:59PM +0100, Jonathan Wakely wrote:

> On Mon, Apr 04, 2005 at 01:08:37PM +0200, tbp wrote:
> 
> > On Apr 4, 2005 1:04 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > > Hope that helps,
> > Yes, thanks and for once gcc warning was explicit enough (with a hint
> > about namespace) for me to fix it.
> 
> :-)
> It might be even better if the error indicated that only the definition
> needs to be in the same namespace. 

gah! ignore the sentence above, my brain wasn't firing right, this is
what I meant:

> What I mean is that GCC rejects the following code saying:
> 
> test.cc:7: error: specialization of `template void dummy::foo::f()' in 
> different namespace
> test.cc:3: error:   from definition of `template void dummy::foo::f()'
> 
> but actually the specialisation and definition are both in the global
> namespace:
> 
> namespace dummy {
> struct foo {
> template  void f();
> };
> }
> template  void dummy::foo::f() {}
> template<> void dummy::foo::f<666>() {}
> 
> The error is that the specialisation is in a different namespace from
> the declaration, not the definitionn.
> 
> Does anyone agree? Should I file a PR?
> 
> jon

Re: Help me about C language Specification

[Jonathan Wakely]

On Wed, Apr 13, 2005 at 03:30:31PM +0700, thanh tuan wrote:

>   Hello,
> I am a student, and I am studying to build an ANSI C compiler into
> ASM. The things I need now are the ANSI C specification ( or something
> about  the state machine, automata to do lexeme and syntax...)
> Please tell me where I can get this. Thank you very much!

Hi,

you can buy a PDF online from ANSI's web store 
or you can buy a book published in the UK by Wiley, ISBN 0470845732.
There might be other ways to buy it from your national standards body.

regards,

jon

Re: implicit type cast problem of reference of ponter to const type

[Jonathan Wakely]

On Sat, Apr 16, 2005 at 01:13:46PM +0800, Steve Yee wrote:

> the following code can not compile. is it due to the standard?

Yes, this is not valid C++.  int* -> const int* creates a temporary and
you can't bind a non-const reference to a temporary.

You might mean
void testfun(int * const & pr)
or just
void testfun(int * pr)

GCC is correct to reject this code so if you want more information you
should try somewhere like comp.lang.c++

> void testfun(const int *&pr)
> {
> }
> 
> main()

Should be "int main()"

> {
>  int *p;
>  testfun(p);
> }

hope that helps,

jon

-- 
"Democracy is the theory that the common people know what they want, and 
 deserve to get it good and hard."
- H.L. Mencken

Re: GCC 4.1: Buildable on GHz machines only?

[Jonathan Wakely]

On Wed, Apr 27, 2005 at 08:05:39AM -0700, Matt Thomas wrote:

> David Edelsohn wrote:
> 
> > GCC now supports C++, Fortran 90 and Java.  Those languages have
> > extensive, complicated runtimes.  The GCC Java environment is becoming
> > much more complete and standards compliant, which means adding more and
> > more features.
> 
> That's all positive but if GCC also becomes too expensive to build then
> all those extra features become worthless.

Worthless to whom?

The features under discussion are new, they didn't exist before.

If you survived without them previously you can do so now.
(i.e. don't build libjava if your machine isn't capable of it)

But claiming it's "worthless" when plenty of people are using it is
just, well ... worthless.

jon

-- 
"Speed, it seems to me, provides the one genuinely modern pleasure."
- Aldous Huxley

Re: g++, initialization of Array if its is a class member.

[Jonathan Wakely]

On Wed, May 04, 2005 at 05:18:56PM +0200, Wlodzimierz Lipert wrote:

>  Hi! A little mistake during copy/paste. :)
>  
>  template < typename T, int S >
>  class A{
>  
>  public:
>  T _V[S ];
>  int a;
>  }

You're missing a ';' here.

>  
>  template < typename T >
>  class B : public A< T, 2 /* const */ >
>  {
>  B( T t ) : A::V[0]( t ), A::V[1] ( t ) /* ERROR reported by

This is not legal C++

The initialisation list must name base classes and members.

A::V is not a member of B, so cannot be initialised here.
A::V[0] is also not a member, and you cannot initialise the
elements of an array like this anyway.

>  compiler. Why? */
>  , a( 1 ) /* no error */ {};

Are you sure?  This is an error. 'a' is not a member of B.

>  
>  B( T t1, T t2 ){
>  A::V[0] = t1; // no error.
>  }
> 
>  };
>  
>  It apears that index operator [] is not treated properly during 
> initialization.

-- 
"All that we are is the result of what we have thought;
 it is compounded of our thoughts, made up of our thoughts."
- Dhammapada, Verse I

Re: Mail. Mail! Mail?

[Jonathan Wakely]

On Tue, May 10, 2005 at 03:37:13PM +0100, Bernard Leak wrote:

> Dear List,
> 
> Firstly, thanks to Bob Proulx for the helpful pointer to the Debian
> search widget.  This is a genuinely useful-looking tool.  How pleasing!
> But unless he thinks this is another thing I should "just know about",
> it's worth documenting *somewhere*.  I don't suggest that the GCC
> documentation should necessarily mention the Debian web-site
> (indeed, it is surely better not to): but the GCC documentation left
> me stuck over "Mail". with nowhere to go.

Patches are welcome.

> How difficult does it have to be to find something out before adding it
> to the documentation looks like a benefit to other people?  Is forcing me
> (and any others in the same position later) to ask an unnecessary
> question something to be encouraged, as an exercise in communal
> living, or something?  Do you all have too much time on your hands?

No, that's why a patch from you would help, even if it's only a starting
point for someone else to improve on.  Many of us are volunteers, so if
something isn't a problem to us then getting round to fixing it doesn't
always seem appealing.  Send a patch to help us out.

I sometimes make changes to the docs when I see something that could be
improved, but currently I'm busy working on other things which cause me
real problems.

> Is there any information you would like to delete from the documentation
> on the same principle?

Probably. Patches welcome.

> I'm not asking anyone to guess at things I might possibly not know and
> explain them in the documentation.  I am asking for two *specific* things
> (which in fact I did not know) to be explained in the documentation,
> because brute-force searching in "the obvious places" doesn't produce
> the Right Thing, but can and does throw up misleading clues to the Wrong
> Thing.  "Mail" in particular is not the name of a GNU utility, but "mail"
> is.  The results submission script uses "Mail".  My distribution has
> "mailx", which completes the set of three!  How confusing and inconsistent
> does it have to be before it seems like a candidate for documentation?

Send a patch, it might get more attention than a request without a
patch.

> hand ("Linux in a Nutshell", 4th Edition).  I have now gone back to
> check: the documentation for "mail" mentions neither "Mail" nor "mailx",
> and I found no references to "Mail" or "mailx" in the index.  I have
> now gone over the "sendmail" documentation (apparently for Big
> Sendmail).  Zack Weinberger's first reply to me is still the only
> indication I've ever noticed that there is more than one thing called
> "sendmail".

Search rpmfind.net for /usr/sbin/sendmail, you'll see lots of
non-sendmail packages provide that executable.

> If you have a lot of time to waste you might try finding "Mail" in
> the Linux Documentation Project tree.  You do have a lot of time
> to waste, don't you?  I mean, it *might* be in there. Somewhere.
> Yes, I tried this at length before I gave up and made my posting.
> Again, I didn't think there was much point in mentioning it.

This isn't GCC's problem. Send a patch  :-)

jon

-- 
I don't pretend to be an expert on intellectual property law, but I do
know one thing. If a music industry executive claims I should agree with
their agenda because it will make me more money, I put my hand on my wallet
... and check it after they leave, just to make sure nothing's missing.
- Janis Ian 

Re: Mail. Mail! Mail?

[Jonathan Wakely]

On Tue, May 10, 2005 at 04:58:03PM +0100, Bernard Leak wrote:

> Dear List,
> 
> Jonathan Wakely wants me to send a patch (or more than one).

:-)

> >Send a patch.
> Will do, after some further digging and sanity-testing, along the lines
> I have already indicated.  Did you expect it already?  I have to
> consider that not all builds of GCC are on UN*X-type boxes.  The
> existing machinery for submitting test results is rather non-portable:
> I don't want to do anything to make it worse.

Cool.  I'm sure plenty of people will be glad to look over it and verify
anything you're not sure about, just mention if you think a certain bit
needs extra attention.

> I've already sent a suggestion to O'Reilly fpr the next edition
> of "Linux in a Nutshell".  I'm thinking what can be done by way
> of producing a one-stop shop for nasty aliases and homonyms
> (libxml=gnome-xml and all the others) to go in the LDP.  Any
> other bright ideas?  Or can someone point me to where it has
> all been done before?

That sounds like a very good idea to me.
Here's one that bothers me when I move between different machines:
soffice / ooffice

jon

Re: GCC 4.1: Buildable on GHz machines only?

[Jonathan Wakely]

On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:

> * I wasn't aware about this fortran specific patch posting policy. I
> never have sent any gcc patch to any other list but gcc-patches for
> approval before, so I also had not done so this time.
> 
> * How could I know that the responsible maintainers aren't listening to
> bugzilla and gcc-patches, but are listening to a fortran specific list,
> I even didn't know about until your posting?

For future reference, where patches should be sent is explained here:
http://gcc.gnu.org/lists.html

jon

Re: GCC 3.4.4

[Jonathan Wakely]

On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:

> I've very nearly ready to release GCC 3.4.4.  If you have objections or 
> high-priority fixes that you think will be required for this release, 
> please speak up within the next 24 hours.

Sorry for the last minute mail ...

It occurs to me that although we're not fixing this in 3.4.4

http://gcc.gnu.org/ml/libstdc++/2005-05/msg00105.html

we could document it, which would be a safe change:

Index: docs/html/debug.html
===
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/debug.html,v
retrieving revision 1.7
diff -u -p -b -B -r1.7 debug.html
--- docs/html/debug.html18 Nov 2003 20:56:07 -  1.7
+++ docs/html/debug.html17 May 2005 09:09:06 -
@@ -283,7 +283,9 @@
   under pedantic debug mode libstdc++ would signal an error. To enable
   the pedantic debug mode, compile your program with
   both -D_GLIBCXX_DEBUG
-  and -D_GLIBCXX_DEBUG_PEDANTIC .
+  and -D_GLIBCXX_DEBUG_PEDANTIC (N.B. due to a bug in GCC
+  3.4.x and 4.0.0 you also need -D_GLIBXX_DEBUG_PEDANTIC
+  to fully enable pedantic mode).

 The following library components provide extra debugging
   capabilities in debug mode:


-- 
"An alcoholic is someone you don't like who drinks as much as you do."
- Dylan Thomas

Re: GCC 4.1: Buildable on GHz machines only?

[Jonathan Wakely]

On Tue, May 17, 2005 at 11:05:07AM -0500, Joel Sherrill <[EMAIL PROTECTED]> 
wrote:

> Jonathan Wakely wrote:
> >On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
> >
> >
> >>* I wasn't aware about this fortran specific patch posting policy. I
> >>never have sent any gcc patch to any other list but gcc-patches for
> >>approval before, so I also had not done so this time.
> >>
> >>* How could I know that the responsible maintainers aren't listening to
> >>bugzilla and gcc-patches, but are listening to a fortran specific list,
> >>I even didn't know about until your posting?
> >
> >
> >For future reference, where patches should be sent is explained here:
> >http://gcc.gnu.org/lists.html
> 
> OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?
> 
> A search for "patch" in the bug reporting instructions does not mention
> anything about cc'ing any patch list.
> 
> I'm not trying to be irritating here.  Just pointing out that if there 
> is a procedure, it doesn't appear to be referenced in all the right 
> places and isn't tied to the PR system.

I never claimed it was easy to find!  :)

Ralf was right that posting a patch to bugzilla should get seen by the
relevant maintainers ... I was just pointing out that the procedure for
where to post patches *is* documented *somewhere*, however poorly.

jon

Re: "No matching function" -- not finding copy constructor

[Jonathan Wakely]

On Tue, May 17, 2005 at 09:12:38AM -0700, Joe Buck wrote:

> On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote:
> > I'm upgrading to V4.0.0 and struggling with some code that's seriously
> > into templates.  One puzzling error is this one:
> > 
> > keyed_obj.hh:159: error: no matching function for call to 
> > 'CxnIndex::CxnIndex(CxnIndex)'
> > Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex&)
> > Indeces.hh:145: note: ... and some more
> > 
> > It's not entirely clear to me why something very much like a copy
> > constructor is being invoked in the first place.  But the bigger
> > puzzle is: why isn't the copy constructor being matched?  I would have
> > thought that any call with a T argument should match a function or
> > method with an &T argument in its declaration...
> 
> CxnIndex::CxnIndex(CxnIndex&) is not a general copy constructor.  Notice
> the non-const reference.  The error message is saying that it's trying
> to pass a temporary to a copy constructor.  You would need
> 
> CxnIndex::CxnIndex(const CxnIndex&)
> 
> to match that.  As for why you need a copy constructor, we'd have to
> see the code for that, but this list isn't really the right place for
> helping you debug this problem further.

One GCC-related point is possibly worth mentioning: GCC is now much
stricter about enforcing the rule that a copy constructor must be
accessible even if the copy will be elided.

See the last entry of http://gcc.gnu.org/bugs.html#nonbugs_cxx

jon

Re: GCC 3.4.4

[Jonathan Wakely]

On Tue, May 17, 2005 at 02:11:24PM -0700, Mark Mitchell wrote:

> Jonathan Wakely wrote:
> >On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:
> >
> >
> >>I've very nearly ready to release GCC 3.4.4.  If you have objections or 
> >>high-priority fixes that you think will be required for this release, 
> >>please speak up within the next 24 hours.
> >
> >
> >Sorry for the last minute mail ...
> >
> >It occurs to me that although we're not fixing this in 3.4.4
> >
> >http://gcc.gnu.org/ml/libstdc++/2005-05/msg00105.html
> >
> >we could document it, which would be a safe change:
> 
> Great idea!  Go ahead, please.

Oops, I meant to send this to the libstdc++ list, sorry for that.

jon

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Jonathan Wakely]

On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:

> On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
> > If I build main with C1, and libf.so with C2, and execute the program so 
> > that it uses C2's libgcc_s.so.1, it works.
> 
> Out of interest, what happens if you build main with C2 and libf with C1?
> That would seem to be a more common situation for distributors of Linux
> binaries than the other way around.
> 
> This policy of not supporting "build on newer, run on older" is a massive
> pain for developers who distribute Linux binaries even though it's very
> common: developers often use very new distributions but users often don't.
> It requires all kinds of stupid hacks to work around. 

Such as compiling on an older system?
That's not a stupid hack, it's responsible library development IMHO.

Develop on your sexy new system, build releases on the old one
(which as Jakub points out, could be a chroot'd part of the same system)

> Could there please at some point be serious discussion of making this a
> supported way of working? In this case dl_iterate_phdr is weak so could
> the decision about whether to use it or not could be made at runtime, not
> build time?

How do you propose to make existing, installed libraries compatible with
all future versions that might exist at some point? :)

My favourite solution is to ship source, so users can compile it
themselves.  Problem "solved"  ;)

jon

-- 
"This Statement is False"
(Courtesy of POEE)

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Jonathan Wakely]

On Thu, May 19, 2005 at 02:22:42PM +0100, Mike Hearn wrote:

> On Wed, 18 May 2005 22:02:37 +0100, Paul Brook wrote:
> > Rubbish. You've obviously never tried to install two third party windows 
> > applications that require two different revisions of msvcrt.dll, or even 
> > worse two random versions of an OCX control.
> 
> And Linux has dependency hell. 

But many Linux/UNIX apps ship as source, so you can resolve those dep's
by rebuilding.  That may not be practical for all users, but for those
prepared to do it, it works.

> As a long time contributor to the Wine project, I think I know what
> problems Windows has with dynamic linking. I never said it was perfect.
> 
> Nonetheless, Windows (especially in the past few years) has significantly
> fewer issues with this than Linux does. Partly that's because the
> Microsoft toolchain doesn't helpfully give you dependencies on Windows XP
> without you asking - for obvious reasons!

Neither does Linux - by linking against a recent library you are
*asking* for a binary that requires that library.  If you understand
that you might understand why everyone is saying you should build on the
lowest common denominator of the systems you're targetting.

If you insist on shipping executables not just source then you have to be
prepared to make a bit more effort to make them distributable.  You're
aware of the problems, but seem to be resisting everyone's advice on how
to avoid them.

>   Can you imagine the bad
> publicity they'd get if it looked like they were trying to force people to
> upgrade?

jon

Re: Problems building gcc on my mandrake

[Jonathan Wakely]

On Fri, May 20, 2005 at 12:35:26PM -0400, Mehul wrote:

> Hi,
> 
> I am trying to build/install gcc on my Linux laptop and I am having
> problems doing that. I have read through the documentation and nothing
> seems to help me out. I would therefore like some1 to help me out.

This list is for GCC development, your question is better suited to
[EMAIL PROTECTED]

> I downloaded gcc.4.0.0, unzipped, after which I had two directories
> under the main directory gcc and libs***. The documentation says that
> I need to create separate directory for object files. but under which
> direcrtory should I  create them.

Neither, create it somewhere else, _anywhere_ else - but not in the same
directory as the sources.

> It says once I am done configuring I shoudl run the configure script
> to build it. I couldnt find a configure script under gcc, all I have
> is *.c files. I found one under libs directory but when I try to
> run that it says
> "configure: error: cannot find install-sh or install.sh in . ./.. ./../.."
> 
> Can some1 please tell what I doing wrong.

What about in the top-level directory above gcc and lib*** ?

This should work:

tar xzvf gcc-X.Y.Z.tar.gz
[creates a directory called something like gcc-X.Y.Z]
mkdir obj
cd obj
../gcc-X.Y.Z/configure


jon

Re: GCC 3.4.4 Released

[Jonathan Wakely]

On Fri, May 20, 2005 at 12:00:17PM -0700, Joe Buck wrote:

> On Fri, May 20, 2005 at 10:15:12AM -0700, Mark Mitchell wrote:
> > And, I would like to ask that our webmasters, in there copious spare 
> > time :-), work on automatically generating more of this content.  The 
> > bug lists and such could be automatically generated, even if some 
> > subsequent refinement is required.
> 
> We don't have enough data to reliably generate the bug list completely
> automatically, especially for new releases on older branches.

How about an "opt in" scheme, where a particular bugzilla keyword means
"add this to the list of fixed bugs" ?

e.g. if the bug's owner adds bugfix-3.4.4 it appears in the list

This might not be appropriate for a keyword, but something in the
comments maybe.  It would have to be checked before release, to ensure
it hadn't been added incorrectly, or the patch reverted etc.

jon

-- 
"Neither a man nor a crowd nor a nation can be trusted to act humanely, or
 to think sanely, under the influence of a great fear."
- Bertrand Russell

Re: Hello,Gnu

[Jonathan Wakely]

On Tue, May 31, 2005 at 08:58:14AM -0700, dk zhou wrote:

> I want to use gcc to compile program for windows,how
> can i get it?

http://www.google.com/search?hl=en&lr=&q=%22gcc+for+windows%22&btnG=Search

you probably want MinGW

jon

Re: help needed

[Jonathan Wakely]

On Wed, Jun 01, 2005 at 04:22:24AM -0700, sandeep nadkarni wrote:

> Hello,

Hi,

> I'm trying to migrate from open vms to Linux. I'm
> compiling programs on Linux which are running on open
> VMS
> 
> I'm facing problem with int64 function. 

What problem?  Which function?

> my hardware configuration is P-IV 3.06 GHz
> 512 MB, 
> I'm Running Fedora Core 3 with gcc
> Reading specs from
> /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
> Configured with: ../configure --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib
> --enable-__cxa_atexit --disable-libunwind-exceptions
> --enable-java-awt=gtk --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) 
> 
> can i compile the same with this? what compiler option
> will i have to use? 

You haven't given much information but as your question is about using
GCC (not developing it) you might get a better answer by mailing
[EMAIL PROTECTED]

The gcc@gcc.gnu.org list is for GCC development.

Regards,

jon


-- 
"Anyone who cannot cope with mathematics is not fully human.
 At best, he is a tolerable subhuman who has learned to dress himself,
 bathe, and not make messes in the house."
- Robert Heinlein

Re: GCC 4.01 RC1 Available

[Jonathan Wakely]

On Wed, Jun 08, 2005 at 09:57:55AM -0700, Mark Mitchell wrote:

> The GCC 4.0.1 RC1 prerelease is available here:
> 
>   ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
> 
> Please test these tarballs, and let me know about showstoppers.

I downloaded the gcc and gcc-g++ tarballs. x86_64 linux (FC3):

$ ../gcc-4.0.1-20050607/configure --enable-languages=c,c++
... configures OK ...
$ make bootstrap
... bootstraps OK ...
$ make check
make[1]: Entering directory
`/home/redi/src/gcc/tmp/build401/fixincludes'
autogen -T ../../gcc-4.0.1-20050607/fixincludes/check.tpl
../../gcc-4.0.1-20050607/fixincludes/inclhack.def
make[1]: autogen: Command not found
make[1]: *** [check] Error 127
make[1]: Leaving directory `/home/redi/src/gcc/tmp/build401/fixincludes'
make: *** [check-fixincludes] Error 2

"make -k check" continues OK (and is still running), but should a release
be looking for autogen like that?

jon

Re: GCC 4.01 RC1 Available

[Jonathan Wakely]

On Thu, Jun 09, 2005 at 04:12:40PM -0400, Andrew Pinski wrote:

> 
> On Jun 9, 2005, at 3:54 PM, Jonathan Wakely wrote:
> 
> >On Wed, Jun 08, 2005 at 09:57:55AM -0700, Mark Mitchell wrote:
> >
> >>The GCC 4.0.1 RC1 prerelease is available here:
> >>
> >>  ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
> >>
> >>Please test these tarballs, and let me know about showstoppers.
> >"make -k check" continues OK (and is still running), but should a 
> >release
> >be looking for autogen like that?
> 
> fixincludes checking always have needed autogen.  This is not new.

OK, sorry for the silly question then.  Thanks.

jon

Re: help using mingw/gcc

[Jonathan Wakely]

On Wed, Jun 15, 2005 at 11:31:40AM -0500, [EMAIL PROTECTED] wrote:

> Hello, I'm trying to compile a simple program with gcc on windows and am 
> getting really frustrated. I've tried entering the commands in command 
> prompt (no ms-dos mode, I have XP) and Run, but can't get anything, 
> mostly something like "no such directory" or "gcc is not a valid 
> command". Any suggestions?

This mailing list is about development *of* GCC, not *with* GCC, so your
question would be better suited to the gcc-help list (which is for help
using GCC) or some other forum about Windows command-line use.

At a guess, I'd say it sounds like you need to set your path variable,
or give the full path to GCC, but I never use Windows for anything
serious so I wouldn't know.

Finally, if you want anyone to help you, you'll probably need to give
more information than that.  If you want someone to take time to help
you you should at least take the time to explain exactly what errors you
got.

Good luck,

jon

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Jonathan Wakely]

On Thu, Jun 16, 2005 at 10:30:03AM -0400, Scott Robert Ladd wrote:

> Aaron W. LaFramboise wrote:
> > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this
> > the "Bicycle shed effect."
> > 
> > 
> 
> If I'm building a bicycle shed, I may want to talk with others who have
> done so in the past, learning from the experience and gaining their
> insights. Why did they use a certain type of construction? What sort of
> storage did they build in? What worked and didn't work for someone else
> who has already built a shed? What did they learn from their own work?
> Any shed I build will be better for such discussions.

You've completely missed the point (rather appropriately).  You're
*supposed* to be building a nuclear reactor, but have got preoccupied
discussing the colour of the bicycle shed in which the staff will park
their bikes.

That's what "bicycle shed painting" refers to.

> GCC's floating-point support can be improved by considering what people
> want from their math in conjunction with the characteristics of
> different systems. Discussions herein have clarified and expanded my
> understanding of the issues.
> 
> > In all of the open source world I have seen, posting code is always better.
> 
> Better than what? Design? Analysis? Just because some people like to
> nitpick doesn't mean there shouldn't be forethought to our work.

The point Aaron is making is that discussion of such topics very rarely
results in any useful design or analysis, because every Tom, Dick and
Harry pipes up to add their 2c, the majority of which are completely
irrelevant. (Look, I'm contributing to it, and I'm completely irrelevant
to the discussion).

If this thread had resulted in any useful design or analysis noone would
mind, but it's turned into a multi-headed beast covering the etiquette
of bugmasters, the names of vapourware compiler switches, and alien
invasion (though that was very funny). Oh, and whether PR323 is a bug,
of course.

The only remaining place this thread can go (before satisfying Godwin's
rule) is for the resident markov generator to correct you all by pointing
out that the linker on MMIX platforms uses UTF-8 for the symbol names.

(what do you mean it's not friday afternoon yet?)

jon

Re: libstdc++-libc6.1-1.so.2 libraries

[Jonathan Wakely]

On Sun, Jun 19, 2005 at 06:49:32PM -0400, Bill wrote:

> Below is the error I receive when attempting to run a newly installed
> version of netscape 4.79 on centOS 4.0 (RHEL 3), which is my personal
> computer at home. This is the only browser that works on linux that is
> compatible with the Thorium installer for BMC Patrol. I downloaded the
> browser from netscapes website browser archive and used the
> prepackaged installer script with all defaults.
> 
> [EMAIL PROTECTED] ~]$ cd /opt/netscape
> [EMAIL PROTECTED] netscape]$ ./netscape
> ./netscape: error while loading shared libraries:
> libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
> or directory

You need to get the right package for your OS.  For redhat distros that
would be an RPM something like compat-libstdc++-7.3-2.96.126.i386.rpm

For CentOS I poked around for 2 mins and found this:
http://www.sunsite.org.uk/sites/msync.centos.org/CentOS/4.0/os/i386/CentOS/RPMS/compat-libstdc++-296-2.96-132.7.2.i386.rpm
which might be what you want.

jon

Re: sizeof() function parameter array: known problem?

[Jonathan Wakely]

On Fri, Jul 01, 2005 at 10:45:19AM +0200, Etienne Lorrain wrote:

>   The result of this funtion is 1, is there a C lawyer around?

The parameter is treated as unsigned* since an array is converted to
a pointer when passed through a function.

C99 says in 6.7.5.3:

   [#7] A declaration of a parameter as ``array of type'' shall
   be adjusted to ``qualified pointer to type'', where the type
   qualifiers (if any) are those specified within the [  and  ]
   of  the  array  type derivation.

> $ cat tmp.c
> unsigned fct (unsigned array[10])

These prototypes are all equivalent, and any sized array (or just a
plain pointer) can be passed to them:

unsigned fct (unsigned array[10]);
unsigned fct (unsigned array[]);
unsigned fct (unsigned* array);

> {
> return sizeof(array) / sizeof(array[0]);
> }

Therefore what you're testing is sizeof(unsigned*)/sizeof(unsigned)
which is 1 on x86 and most other 32-bit targets (but 2 on e.g. x86_64)

Hope that helps,

jon

Re: Calling a pure virtual function

[Jonathan Wakely]

On Sat, Jul 09, 2005 at 08:41:47PM +1000, Adam Nielsen wrote:

> Hi all,
> 
> I was expecting the following code snippet to work, so am I doing
> something wrong, or is there an issue with GCC?  I was under the
> impression that this is allowed, according to
> http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.1

As you've discovered, FAQ 23.3 gives more detail.

> It seems like GCC initially allows it as it starts to compile okay, but
> then I get an undefined reference error from the linker (because it
> seems to be actually calling Base::number(), which obviously won't work
> as it's a pure virtual function.)

It's allowed, and will work, but you have to provide a definition for
the function.  Calling number() from the base constructor calls
Base::number() so you have to define it.

GOTW 31 discusses topics related to this: http://www.gotw.ca/gotw/031.htm

GCC is doing exactly the right thing here, it's not possible to tell
that the definition of Base::number() is missing until link time.

jon

Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures

[Jonathan Wakely]

On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote:

> On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> > On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> 
> > > Joe Buck reports the same problems on SPARC/Solaris:
> > > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html
> > >
> > > According to my testing, the fix is to upgrade to GNU Binutils 2.16 or 
> > > 2.16.1.
> > 
> > you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora
> > core development) would suffice? or anyone else??
> 
> or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates?

That version works for me on x86_64.

The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know
about the rest of GCC.

jon

Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures

[Jonathan Wakely]

On Tue, Jul 12, 2005 at 01:23:23PM +0200, Karel Gardas wrote:

> 
> Hello,
> 
> On Tue, 12 Jul 2005, Jonathan Wakely wrote:
> 
> >On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote:
> >
> >>On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> >>>On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> >>
> >>>>Joe Buck reports the same problems on SPARC/Solaris:
> >>>>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html
> >>>>
> >>>>According to my testing, the fix is to upgrade to GNU Binutils 2.16 or 
> >>>>2.16.1.
> >>>
> >>>you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora
> >>>core development) would suffice? or anyone else??
> >>
> >>or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates?
> >
> >That version works for me on x86_64.
> >
> >The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know
> >about the rest of GCC.
> 
> does this also apply to other than sparc platforms? I'm cunfused by your 

I believe that version applies to x86 linux and x86-64 linux.  I don't
know about Sparc linux.  The only hard fact I can confirm first-hand is
that the latest binutils from FC3 updates works for me on x86_64.

> note about x86_64, since I'm not able to find any notes about minimal 
> binutils 2.15.90.0.1.1 version required for libstdc++ build on AMD64 
> linux. Especially:
> 
> http://gcc.gnu.org/install/specific.html
> 
> notes more recent binutils version than 2.15 release only in case of 
> *-*-solaris2* configuration.

Yes, I know.  I'm in the process of updating the libstdc++ docs here,
which are very out of date:
http://gcc.gnu.org/onlinedocs/libstdc++/install.html#prereqs

I will also have to add something to the main config docs to say that
libstdc++ (and other runtime libs) may have more specific requirements,
so check the relevant docs.

jon

Re: libstdc++ required binutils version [was: Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures]

[Jonathan Wakely]

On Tue, Jul 12, 2005 at 01:55:11PM +0200, Karel Gardas wrote:

> On Tue, 12 Jul 2005, Jonathan Wakely wrote:
> 
> >>On Tue, 12 Jul 2005, Jonathan Wakely wrote:
> >>
> >>>The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know
> >>>about the rest of GCC.
> >>
> >>does this also apply to other than sparc platforms? I'm cunfused by your
> >
> >I believe that version applies to x86 linux and x86-64 linux.  I don't
> >know about Sparc linux.  The only hard fact I can confirm first-hand is
> >that the latest binutils from FC3 updates works for me on x86_64.
> 
> Interesting! Please have a look at:
> http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00602.html
> 
> those are test results from 4.0.1 release compiled on debian 3.1/AMD64 
> (pure64 bit). This debian is using binutils 2.15:
[snip]
> and IMHO testresults look quite good except abi_check, don't they? i.e. do 
> you mean updating binutils will resolve abi_check issue in libstdc++ 
> testsuite?

I'd assume yes, based on Benjamin's statement here:
http://gcc.gnu.org/ml/libstdc++/2005-06/msg00132.html

But I don't know what's really causing the abi_check failure.

I've CC'd the libstdc++ list so I hope one of the v3 guys will be able
to answer that for you.

jon

Re: volatile semantics

[Jonathan Wakely]

On Sun, Jul 17, 2005 at 09:29:11PM -0400, Paul Schlie wrote:

> > Note that I'm explicitly not taking a position on what the standard says.
> > The standard is notoriously incomplete with respect to object model issues,
> > including volatility, so I think that trying particularly hard to parse its
> > words in this area is probably not a good use of time for people trying to
> > build a real-world compiler. Creating DRs is more useful than trying to read
> > the tea leaves.
> >
> > Clearly, the analogous rule does not make sense for "const" in that a 
> > "const"
> > object can never be modified; in particular, if the compiler can prove that
> > "*x = 3" is an attempt to modify an object whose dynamic type is "const 
> > int",
> > then it can replace that with a call to "kill (SIGSEGV)", if it likes; this
> > is unquestionably undefined behavior.
> 
> With all due respect, unless there is an explicit reference in the standard
> to contradict it's clearly stated requirement that an object's qualified
> lvalue ("locator value") designates the object being referenced, all
> interpretations to the contrary are at best presumptuous, regardless of
> whether or not it's generalized behavior may be indeterminate.

Does the first sentence of the following text count?

  6.7.3  Type qualifiers

   [#5] If an attempt is made to modify an object defined  with
   a  const-qualified  type  through use of an lvalue with non-
   const-qualified type, the  behavior  is  undefined.   If  an
   attempt  is  made  to  refer  to  an  object  defined with a
   volatile-qualified type through use of an lvalue  with  non-
   volatile-qualified type, the behavior is undefined.113)

jon

Re: No download link from gcc.gnu.org

[Jonathan Wakely]

bhiksha wrote:

> I simply cannot find any direct link to a downloadable source/binary  
> bundle for gcc4 from
> gcc.gnu.org.

Starting from the home page:  "releases", "mirror sites", pick a mirror.

Or "GCC 4.0.1 has been released.", where it tells you it is available
from the mirror sites, then pick a mirror.

Or just pick "mirrors" from the menu on the home page.

> The list of releases on the releases page ends at 3.4.4. Every other 
> link Ive chased down
> stops at 3.4.4.

You're looking at the timeline of releases.  Look above that at the
section with the heading "Download" and read what it says.  It tells you
you can get the source from a mirror and that there are binaries
available for some platforms.

> 4.0  can eventually be found, sans any documentation about what specific 
> files one must download,
> if one digs several links deep, from various sites around the world, but 
> the gcc maintainers themselves
> have not linked it to the main web page.
> 
> This is sad and absurd.   There must be a link to a download site. 
> Otherwise, there must be some
> explicit info on where to obtain it from.
> 
> I suspect that the GCC team simply did not consider it important enough 
> to put up the release in
> an easily accessible place..

The 4.0.x releases are in the same place as all other releases.

If you don't want to build GCC from source and there isn't a precompiled
binary then you still might be able to get a binary version (e.g. if
you're using Linux you might be able to get an .rpm or .deb file for
your distribution)

jon

Re: ISO C++ forbids initialization in array new?

[Jonathan Wakely]

WU Yongwei wrote:

> Well, I see this in the gcc error message.  Can someone here kindly
> point to me which part of the Standard specified this behaviour?  I
> thought it should be in 5.3.4, but was not able to find the words
> there.

It might be better if the error message said "non-default
initialization" since default initialization is allowed (and required).

I assume you are trying something like this:

int* i = new int[5](23);


A new initializer must have the form (...) (see 5.3.4/1) and the only
way that can be used to initialize an array is for default construction.


This is OK, and default initialises the array, which default initialises
each element (8.5/5)

int* i = new int[5]();

but this is not OK:

int* i = new int[5](23);

because it is not valid to initialise an array like this:

typedef int (five_ints)[5];
five_ints i(23);

this gives:

array_init.cc:8: error: cannot initialize arrays using this syntax

HTH

jon

-- 
sigfault

Re: ISO C++ forbids initialization in array new?

[Jonathan Wakely]

Jonathan Wakely wrote:

> WU Yongwei wrote:
> 
> > Well, I see this in the gcc error message.  Can someone here kindly
> > point to me which part of the Standard specified this behaviour?  I
> > thought it should be in 5.3.4, but was not able to find the words
> > there.
> 
> It might be better if the error message said "non-default
> initialization" since default initialization is allowed (and required).

Oops! that was meant to say "required for some types" (e.g.
const-qualified types, non-POD types)

Too early in the morning for me to be answering questions like this!

jon

Bugzilla error

[Jonathan Wakely]

I like the new theme, by the way.

I've just tried to add a comment to a bug I created yesterday and got
this error:

Unknown Known To Work Version
3.3.3 is not a known version for use in the known to work field.
The legal versions are listed in the version popup. 

I've been able to add the comment now so the problem's fixed, but the
error is a bit confusing, as there is no version popup if you're editing
an existing bug.  There's a "Target Milestone" dropdown, which is about
as close as anything on the page, but the two lists are not the same.
Even on the new bug page there's a Version select box, not a popup.

Not terribly critical to fix, obviously :)

jon

Re: Wishlish: GCC option for explicit booleans

[Jonathan Wakely]

Peter Lupton NCH Swift Sound wrote:

> But I have been going through other reports from the 'bug book' which I ask 
> my programmers to log. Another case which explicit bools would solve would 
> be (in Win32)...
> 
> HANDLE hFile = CreateFile(...);
>   if (!hFile) return;
> 
> If the compiler had forced the writer to make a real comparison, I am sure 
> the bug would never have made it into release.  The problem here is 
> INVALID_HANDLE_VALUE is -1 not 0.

It wouldn't help if the test was "corrected" to this:

  if (hFile==0) return;
or
  if (!bool(hFile)) return;

which I can imagine happening very easily if someone is modifying a
whole code base to conform to the new rules.  Once they've "corrected"
it like that, it compiles again and the bug remains unfixed.  If someone
has made the mistake of thinking the invalid value is 0, I think that's
unrelated to whether ints convert to bool.  Code review seems like the
best place for this bug to be caught IMHO. The difficulty of verifying
the correct handling of magic numbers returned as error codes is an
argument for using exceptions.  If you need to use functions like
CreateFile that don't throw, then wrap them in another function that
does and then you only have to verify that the right value is checked in
that one place.  C++ provides better ways to avoid this error than
disabling int -> bool conversions (again, IMHO.)

As for your strcmp() example, that would break all code that says:

   if (!strcmp(s,t))

Unless you make operator!(int) return bool (which would seem sensible to
me,) but then your HANDLE example wouldn't be caught.

Personally I don't think the pros outweigh the cons of this idea.

Regards,

jon

Re: Speed impact of virtual inheritance

[Jonathan Wakely]

Frans Englich wrote:

> In a large project I'm participating in, a design dilemma have arrived. 
> Adding 
> virtual inheritance would solve it beautifully on the source code level, but 
> a potential drawback is the speed penalty it brings. Measurement is always 
> the way of approaching performance questions, but since that sometimes can be 
> tricky, I thought of starting with getting a theoretical understanding of 
> virtual inheritance.

If you don't mean "virtual inheritance as implemented by GCC" then this
is probably the wrong place for such a question.

For an understanding of how it's implemented try "Inside the C++ Object
Model" by Stan Lippmann, and this draft report (especially section 5.3.6)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1666.pdf

That's by a well-respected member of the standard committee, so you can
take it pretty seriously.  I'd certainly give it more credence than
unsubstantiated claims thrown up by googling.

Regards,

jon

Re: specific instantiation of static members from template class

[Jonathan Wakely]

cedric wrote:

> 
> hello, I have a problem when I try to instantiate static members. this code 
> works with gcc-3.4.5 but not with gcc-4.0.2 (debian sid).
> here a test case with 3 files :
> 
> 
> / main.cpp
> #include 
> #include "Test.h"
> 
> int main(int argc, char **argv)
> {
>   std::cout << TestInt::member << std::endl;
>   return 0;
> }
> 
> / test.h
> template 
> class Test
> {
> public:
> 
>   static T member;
> };

add this line here:
template  T Test::member;

> typedef Test TestInt;
> 
> / test.cpp
> #include "Test.h"
> 
> template class Test;

Either remove this line or place it before the explicit instantiation:

> template<> int Test::member;

I think GCC is right here.

jon


-- 
"God is as real as I am," the old man said.  My faith was restored, for
I knew that Santa would never lie.

Wiki pages on tests cases

[Jonathan Wakely]

Why are there two separate wiki pages on test case writing?

http://gcc.gnu.org/wiki/HowToPrepareATestcase
http://gcc.gnu.org/wiki/TestCaseWriting

The second one seems fairly gfortran-specific, but doesn't mention that
fact anywhere.  If the second page adds info that is generally useful to
the whole compiler, that info should be in the first page.  If it
doesn't, it should clearly say it is gfortran-specific, or should be
removed.

Yes, I know it's a wiki and I can do this myself, but I only have so
much spare time and maybe the second one was added for a good reason.

jon

Re: matching function for out_waiting in gcc 3.4.2

[Jonathan Wakely]

Hi,
this question is not about development of GCC so should be moved to
either [EMAIL PROTECTED] or [EMAIL PROTECTED] - I suggest the
former.  Please send any other replies to the libstdc++ list, thanks.

On Mon, Nov 28, 2005 at 02:03:21PM +0530, [EMAIL PROTECTED] wrote:
> I have moved to gcc version 3.4.2(linux sll) So I am migrating a
> component to this version from gcc 2.96. 
>
> In my existing code I am using the *out_waiting* function of the struct
> streambuf present in the streambuf.h file.
> 
> But I can't find this function in this version of gcc 3.4.2. so can u
> help me in finding a matching function in this version.

The function was available on "classic" iostreams, but is not included in
the std::streambuf class from the C++ standard.  Because libstdc++ aims
to be standard-conforming, it does not provide the classic iostreams API.
There is no direct equivalent of out_waiting for std::streambuf.

If you need to know the number of characters in the put area you could
define your own derived streambuf and implement out_waiting in terms of
the protected member functions std::streambuf::pptr() and
std::streambuf::pbase(), and use that where necessary.

I hope that helps a little,

jon

Re: Wiki pages on tests cases

[Jonathan Wakely]

On Mon, Nov 28, 2005 at 12:45:41AM -0800, Jim Blandy wrote:
> On 11/27/05, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > Yes, I know it's a wiki and I can do this myself, but I only have so
> > much spare time and maybe the second one was added for a good reason.
> 
> http://en.wikipedia.org/wiki/Be_bold
> 
> Works for them.

Are you volunteering to do it then?  :)
I'd already proof-read and corrected two pages before I spotted the
duplicate test-writing ones, and am spending what little spare time I
have extending the libstdc++ docs, which for my purposes are more
important.  I wasn't just demanding others do the work while I twiddle
my thumbs!

jon

Re: htsearch broken?

[Jonathan Wakely]

On Fri, Dec 09, 2005 at 08:40:24PM -0800, Will L (sent by Nabble.com) wrote:
> 
> Try search Nabble, the gcc user list is archived here: 
> http://www.nabble.com/gcc---General-f1157.html

Please note this is NOT, I repeat NOT, a GCC users list - this is a GCC
developers list.  There have been several mails sent via nabble.com
to this list that should have been sent to gcc-help instead.

jon

-- 
"Convictions cause convicts"
- Mal2

Re: funny problem with g++

[Jonathan Wakely]

On Wed, Dec 07, 2005 at 11:50:49PM +, Tristan Wibberley wrote:
> 
> IMHO, this is a good extension, at least until boost::array gets
> standardised.

#include 

in GCC 4.0

jon

Missing GNAT docs (was Broken Links on Your Online Docs Web Page?)

[Jonathan Wakely]

On Tue, Jan 10, 2006 at 10:28:26AM -0800, Chris Miller wrote:
> 
> On your online docs web page (http://gcc.gnu.org/onlinedocs/), all the links
> for GCC 3.4.5 GNAT User's Guide bring up a message that the page cannot be
> found.
> 
> The paths for the links look consistent in their format to other links that
> work, which makes me wonder if the docs just aren't there or are there, but
> with filenames or directory names that don't match the link.
> 
> I was interested in having access to the PDF and HTML links for the 3.4.5
> GNAT User's Guide.  Can you help?

Hi,

I can't help to put the 3.4.5 docs there, but the 3.4.4 docs are
available, just change the 5 in the broken URLs to a 4.

I don't know for certain, but I doubt the changes were very significant.

jon

-- 
"Anybody who hates dogs and loves whiskey can't be all bad."
- W.C. Fields

Re: contrib/gcc_update does not work

[Jonathan Wakely]

On Tue, 14 Jan 2020 at 09:22, Uros Bizjak  wrote:
>
> gcc_update, when called from newly initialized and pulled tree does not work:

Initialized how?
If you do a 'git clone' then it correctly checks out master and sets
it to track origin/master.

>
> --cut here--
> $ contrib/gcc_update
> Updating GIT tree
> There is no tracking information for the current branch.
> Please specify which branch you want to rebase against.
> See git-pull(1) for details.
>
> git pull  
>
> If you wish to set tracking information for this branch you can do so with:
>
> git branch --set-upstream-to=origin/ master
>
> Adjusting file timestamps
> git pull of full tree failed.
> --cut here--
>
> I would also appreciate a simple step-by step instructions on how to
> set-up the local repo and basic workflow with git for "non-power"
> users, as was the case with now obsolete instructions for anonymous
> SVN r/o access [1] and r/w access [2]. Basically, push-my-first-patch
> example.
>
> [1] https://gcc.gnu.org/svn.html
> [2] https://gcc.gnu.org/svnwrite.html

They're still a work in progress:
https://gcc.gnu.org/git.html
https://gcc.gnu.org/gitwrite.html

Re: contrib/gcc_update does not work

[Jonathan Wakely]

On Tue, 14 Jan 2020 at 10:38, Uros Bizjak  wrote:
>
> On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely  
> wrote:
> >
> > On Tue, 14 Jan 2020 at 09:22, Uros Bizjak  wrote:
> > >
> > > gcc_update, when called from newly initialized and pulled tree does not 
> > > work:
> >
> > Initialized how?
>
>  1035  mkdir gcc
>  1036  cd gcc
>  1037  git init
>  1038  git pull https://gcc.gnu.org/git/gcc.git

Don't do that :-)

You've created an new, empty repository and then filled it with the
content from gcc.gnu.org/git/gcc but that's not the same as making a
clone of that repo. You could make it the same, but you'd have to do a
lot more steps manually. Just use 'git clone'.

> > If you do a 'git clone' then it correctly checks out master and sets
> > it to track origin/master.
>
> I see, I'll try this now.

Re: git conversion in progress

[Jonathan Wakely]

On Tue, 14 Jan 2020 at 11:37, Georg-Johann Lay  wrote:
>
> Am 14.01.20 um 12:34 schrieb Andreas Schwab:
> > On Jan 14 2020, Georg-Johann Lay wrote:
> >
> >> git clone --reference original-gcc ...
> >
> > Don't use --reference.  It is too easy to lose work if you don't know
> > what you are doing.
> >
> > Andreas.
>
> Well, then it should not be proposed in git.html then?

It's a work in progress. I've already suggested that worktrees are a
better solution for people who want to work on multiple branches but
save disk space.

Re: contrib/gcc_update does not work

[Jonathan Wakely]

On Tue, 14 Jan 2020 at 12:46, Andreas Schwab  wrote:
>
> On Jan 14 2020, Andrew Pinski wrote:
>
> > On Tue, Jan 14, 2020 at 4:10 AM Richard Biener
> >  wrote:
> >>
> >> On Tue, Jan 14, 2020 at 11:44 AM Jonathan Wakely  
> >> wrote:
> >> >
> >> > On Tue, 14 Jan 2020 at 10:38, Uros Bizjak  wrote:
> >> > >
> >> > > On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely 
> >> > >  wrote:
> >> > > >
> >> > > > On Tue, 14 Jan 2020 at 09:22, Uros Bizjak  wrote:
> >> > > > >
> >> > > > > gcc_update, when called from newly initialized and pulled tree 
> >> > > > > does not work:
> >> > > >
> >> > > > Initialized how?
> >> > >
> >> > >  1035  mkdir gcc
> >> > >  1036  cd gcc
> >> > >  1037  git init
> >> > >  1038  git pull https://gcc.gnu.org/git/gcc.git
> >> >
> >> > Don't do that :-)
> >>
> >> I think it's what the wiki still suggests...
> >
> > Yes the wiki does suggest that but the wiki was about using git mirror.
>
> Even with the old mirror a normal clone was working as usual.  Only if
> you wanted to commit using git svn you needed to do the unusual setup.

I've added a big bold notice to the top of the wiki page:
The information on this page refers to the git-svn mirror WHICH HAS
BEEN RETIRED. While some tips here may still be useful (like the
convenient git aliases) do not follow these steps to use the new Git
repository (which is not a mirror, so obviously this page isn't
talking about it!)

Re: git conversion in progress

[Jonathan Wakely]

On Tue, 14 Jan 2020 at 14:28, Martin Jambor  wrote:
>
> Hi,
>
> On Tue, Jan 14 2020, Andreas Schwab wrote:
> > On Jan 14 2020, Georg-Johann Lay wrote:
> >
> >> git clone --reference original-gcc ...
> >
> > Don't use --reference.  It is too easy to lose work if you don't know
> > what you are doing.
>
> What are the risks, assuming I won't delete the referenced repo which
> sits on the same partition of the same local disk as the new one?

If I understand correctly (and I don't use --reference so I might be
wrong), with --reference you need to do a git fetch in each separate
repo when you want to upate, because although they share objects they
each have their own "view" of the remotes.

If you do a git pull in a clone created with --reference it will fetch
new objects and store them locally, it won't update the referenced
repo. This means they can diverge over time and aren't sharing as much
as possible (I assume that can be resolved by repack or gc? I don't
know).

Also, anything committed to any worktree is instantly visible to the
others. I have worktrees for master, gcc-9 and gcc-8. After I backport
something to gcc-9 (but before I push it upstream) I can go to the
gcc-8 worktree and do 'git cherry-pick gcc-9' to apply the newest
commit from gcc-9 branch to the gcc-8 branch. There's no need to push
or pull anything between the worktrees, because they are all using the
same clone with the same local branches.

> I prefer it to worktree because I often just do have master checked out
> in multiple directories and worktree would be unhappy about that...

Sounds like a good use for branches :-)

> and
> the risk of accidentally deleting the base worktree are IMHO the same as
> the risk of deleting the referenced repo.

For me, there is zero chance that I'll ever think ~/src/gcc/gcc is an
old tree I don't use. It's also the one where I do work on 'master'
(or branches created from 'master') so I'm unlikely to ever think
that's an unwanted throwaway tree that I don't need. With worktrees
you'll only have 'master' checked out in one of your trees, so it
doesn't take a lot of discipline to know which one is the one
containing all the .git/objects and other repository metadata.

> Anything that I am missing?  (In other words, do I know what I am doing? :-)

Re: Help with new GCC git workflow...

[Jonathan Wakely]

On 14/01/20 10:07 -0600, Peter Bergner wrote:

As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I don't
screw up the upstream repo by pushing something to the wrong place. :-)

I know enough that I should be using local branches to develop my changes,
so I want something like:

 git checkout master
 git pull
 git checkout -b 
 
 git commit -m "My commit message1"
 
 git commit -m "My commit message2"
 
 git commit -m "My commit message3"
 

At this point, I get a little confused. :-)  I know to submit my patch
for review, I'll want to squash my commits down into one patch, but how
does one do that?


This is Git, there are a hundred ways ;-)



Should I do that now or only when I'm ready to
push this change to the upstream repo or ???


Totally up to you. You might want to squash some commits early, e.g.
to fix silly typos, but keep most of the branch history intact until
the last minute (to help you remember what you changed and why).
That's my preference.


Do I need to even do that?


If it's a long-lived feature branch you might want to keep the
separate commits and merge them all to master preserving the branch
history (don't take my word for it, I can't remember what we decided
should be the policy for such long-lived branches).

If it's just a short-lived branch to change one thing, or fix one bug,
then what you push should be a single, self-contained commit (even if
you happened to develop it as a series of mini-commits locally).


Also, when I'm ready to push this "change" upstream to trunk, I'll need
to move this over to my master and then push.


Strictly speaking, you don't need to. You can push that branch
directly to master:  git push origin HEAD:master
That will fail unless the current branch is up-to-date with master,
but would work fine if you've already rebased your branch on master,
or if master hasn't moved since you branched.


What are the recommended
commands for doing that?  I assume I need to rebase my branch to
current upstream master, since that probably has moved forward since
I checked my code out.


You can either rebase on the new master (i.e. bring the new stuff from
master into your branch) or the other way around (bring the stuff from
your branch into master).

A pretty straightforward way to do the second way is:

git checkout master
git pull
git merge --squash 
[resolve any merge conflicts]
[build + test again if your branch was behind master]
git push

i.e. pull the changes from your branch onto master, then push.

This leaves your  branch untouched, so you still have
all the history locally for future reference.

There are other ways e.g. 'git rebase --interactive master' and
squash all the commits in the branch that way. Interactive rebases are
awesome, and very useful. It's a fairly manual process, but that gives
you full control. Get familiar with it.

Or, to (non-interactively) rebase your branch on master (which you
might want to do periodically anyway, before you're ready to push
upstream):

git checkout master
git pull
git checkout 
git rebase master
[resolve any merge conflicts]
[build + test]

That's rebased your branch, but not actually squashed the branch
commits yet. You can do that by checking out master and doing a
merge --squash (as above) or just on the branch:

# make this branch's committed state (aka "index") the same as master
git reset master
# but that didn't touch the content of the working directory,
# that still matches your branch, so you can add+commit all the
# files in the working dir that differ from the "index":
git add --all
git commit

This alters your branch's history to be a single commit against
master, which contains all the changes that you'd done on the branch.
I've never used this method, so I hesitate to recommend it. It's the
least obvious way IMO.

And after either of the rebase methods, you still need to get that
single commit onto master to push (unless you're going to push
directly from the branch). So that might be a reason to prefer doing a
"merge --squash" to squash at the same time as pulling the changes
into master (i.e. the first method above).


Also, at what point do I write my final commit message, which is different
than the (possibly simple) commit messages above?  Is that done after I've
pulled my local branch into my master?  ...or before?  ...or during the
merge over?


Doesn't matter. As long as you push a single commit with a good commit
message, it doesn't matter when that was written. Personally I think
doing it at the end when you do the merge --squash to add a single
commit to master.


...and this is just for changes going to trunk.  How does all this change
when I want to push changes to a release or vendor branch?


It's pretty similar. Create a branch from the release branch, merge it
back to the release branch.

Personally, I don't us

Re: Help with new GCC git workflow...

[Jonathan Wakely]

On 14/01/20 17:05 +, Jonathan Wakely wrote:

On 14/01/20 10:07 -0600, Peter Bergner wrote:

As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I don't
screw up the upstream repo by pushing something to the wrong place. :-)

I know enough that I should be using local branches to develop my changes,
so I want something like:

git checkout master
git pull
git checkout -b 

git commit -m "My commit message1"

git commit -m "My commit message2"

git commit -m "My commit message3"


At this point, I get a little confused. :-)  I know to submit my patch
for review, I'll want to squash my commits down into one patch, but how
does one do that?


This is Git, there are a hundred ways ;-)



Should I do that now or only when I'm ready to
push this change to the upstream repo or ???


Totally up to you. You might want to squash some commits early, e.g.
to fix silly typos, but keep most of the branch history intact until
the last minute (to help you remember what you changed and why).
That's my preference.


Do I need to even do that?


If it's a long-lived feature branch you might want to keep the
separate commits and merge them all to master preserving the branch
history (don't take my word for it, I can't remember what we decided
should be the policy for such long-lived branches).

If it's just a short-lived branch to change one thing, or fix one bug,
then what you push should be a single, self-contained commit (even if
you happened to develop it as a series of mini-commits locally).


Also, when I'm ready to push this "change" upstream to trunk, I'll need
to move this over to my master and then push.


Strictly speaking, you don't need to. You can push that branch
directly to master:  git push origin HEAD:master
That will fail unless the current branch is up-to-date with master,
but would work fine if you've already rebased your branch on master,
or if master hasn't moved since you branched.


What are the recommended
commands for doing that?  I assume I need to rebase my branch to
current upstream master, since that probably has moved forward since
I checked my code out.


You can either rebase on the new master (i.e. bring the new stuff from
master into your branch) or the other way around (bring the stuff from
your branch into master).

A pretty straightforward way to do the second way is:

git checkout master
git pull
git merge --squash 
[resolve any merge conflicts]


I forgot to say that you'll need to do 'git commit' after the merge,
whether or not there were conflicts to resolve.

When you merge with --squash it adds the squashed result to the
"index" (i.e. staging area for changes to be committed) but stops
before the actual commit.

When you do the commit Git will start the commit message with all the
individual commit messages from the branch:

Squashed commit of the following:
  
commit d308da36d957feb3736be2754d134926992b3b74

Author: Jonathan Wakely 
    Date:   Tue Jan 14 22:32:45 2020 +

3rd commit message

commit 3d4a8783ba7f6d466d1729b59436a96b67ddf516
Author: Jonathan Wakely 
    Date:   Tue Jan 14 22:32:40 2020 +

2nd commit message

commit e0a27b98135936d4129876babdbe81e22e6e9bbf
Author: Jonathan Wakely 
Date:   Tue Jan 14 22:32:34 2020 +

1st commit message

So that's a good time to produce the final commit message, cutting and
pasting bits from those if needed, or just deleting those lines.


However, on IRC some people are saying that the simple workflow we
should be advising for newbies is to rebase and squash on the branch
(maybe using Jason's 'git reset' command) and then cherry-pick that
onto master (instead of squash-merging). A cherry-pick takes a single
commit from another branch and applies it to the current branch,
roughly equivalent to creating a patch and then manually applying it.


[build + test again if your branch was behind master]
git push

i.e. pull the changes from your branch onto master, then push.

This leaves your  branch untouched, so you still have
all the history locally for future reference.

Re: Help with new GCC git workflow...

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 08:40, Richard Biener  wrote:
>
> On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond  wrote:
> >
> > Peter Bergner :
> > > At this point, I get a little confused. :-)  I know to submit my patch
> > > for review, I'll want to squash my commits down into one patch, but how
> > > does one do that?  Should I do that now or only when I'm ready to
> > > push this change to the upstream repo or ???  Do I need to even do that?
> >
> > If you want to squash a commit series, the magic is git rebase -i. You
> > give that a number of commits to look back at at and you'll get a buffer
> > instructing you how to squash and shuffle that series.  You'll also be able
> > to edit the commit message.
> >
> > I like to write really fine-grained commits when I'm developing, then
> > squash before pushing so the public repo commits always go from "tests
> > pass" to "test pass".  That way you can do clean bisections on the
> > public history.
>
> The question is wheter one could achieve this with branches?  That is,
> have master contain a merge commit from a branch that contains the
> fine-grained commits?  Because for forensics those can be sometimes
> useful.

A "merge commit" is a special kind of commit that creates a commit
with two (or more) parents, and joins two separate trees. We don't
allow that in master or release branches.

But you can definitely take a series of commits from a branch and put
that whole series into master, without squashing them into one commit.
You just have to rebase the patches onto master (or cherry-pick each
one of the series in turn, but rebase is easier for multiple patches).
That makes a series of new commits on master, each one corresponding
to one of he commits in the branch (but new commits with new hashes,
because the new commit has a different parent than the one on the
branch did). That's fine, but it's not a "merge commit".


> That basically would somehow record that a series of commits are "related"
> (the merge commit has two parents).  Of course usually the merge commit
> is empty and thus non-existant but then for branch merges it still
> always exists?

A merge commit might be empty, but it's not non-existent. But we don't
allow merge commits on master, and we don't need to allow them in
order to have a series of related commits go in together.

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 08:15, 马江  wrote:
>
> Hello,
>   After  some google, I find there is no way to control the scope of
> "using" for the moment.  This seems strange as we definitely need this
> feature especially when writing inline member functions in c++
> headers.
>
>   Currently I am trying to build a simple class in a c++ header file
> as following:
>
> #include 
> using namespace std;
> class mytest
> {
>   string test_name;
>   int test_val;
> public:
>   inline string & get_name () {return test_name;}
> };
>
>   As a experienced  C coder, I know that inline functions must be put
> into headers or else users could only rely on LTO. And I know that to
> use "using" in a header file is a bad idea as it might silently change
> meanings of other codes. However, after I put all my inline functions
> into the header file, I found I must write many "std::string" instead
> of "string" which is totally a torture.

It's really not that bad.

>   Can we add something like "#pragma push_using"  (just like #pragma
> pop_macro)? I believe it's feasible and probably not hard to
> implement.

It would create a non-standard, non-portable dialect of C++. We prefer
to avoid adding non-standard extensions these days. You could propose
it to the C++ committee, but I'm pretty sure they would not want such
a thing.

You can already do it anyway, if you put your own code in a namespace
(which is a good idea anyway):

#include 

namespace foo
{
  using std::string;
  class bar
  {
  string name_;
  public
const string& name() const noexcept { return name_; }
  };
}

This doesn't have all the problems of "using namespace" in a header.

Re: Help with new GCC git workflow...

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 09:49, Richard Biener  wrote:
>
> On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely  
> wrote:
> >
> > On Wed, 15 Jan 2020 at 08:40, Richard Biener  
> > wrote:
> > >
> > > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond  wrote:
> > > >
> > > > Peter Bergner :
> > > > > At this point, I get a little confused. :-)  I know to submit my patch
> > > > > for review, I'll want to squash my commits down into one patch, but 
> > > > > how
> > > > > does one do that?  Should I do that now or only when I'm ready to
> > > > > push this change to the upstream repo or ???  Do I need to even do 
> > > > > that?
> > > >
> > > > If you want to squash a commit series, the magic is git rebase -i. You
> > > > give that a number of commits to look back at at and you'll get a buffer
> > > > instructing you how to squash and shuffle that series.  You'll also be 
> > > > able
> > > > to edit the commit message.
> > > >
> > > > I like to write really fine-grained commits when I'm developing, then
> > > > squash before pushing so the public repo commits always go from "tests
> > > > pass" to "test pass".  That way you can do clean bisections on the
> > > > public history.
> > >
> > > The question is wheter one could achieve this with branches?  That is,
> > > have master contain a merge commit from a branch that contains the
> > > fine-grained commits?  Because for forensics those can be sometimes
> > > useful.
> >
> > A "merge commit" is a special kind of commit that creates a commit
> > with two (or more) parents, and joins two separate trees. We don't
> > allow that in master or release branches.
> >
> > But you can definitely take a series of commits from a branch and put
> > that whole series into master, without squashing them into one commit.
> > You just have to rebase the patches onto master (or cherry-pick each
> > one of the series in turn, but rebase is easier for multiple patches).
> > That makes a series of new commits on master, each one corresponding
> > to one of he commits in the branch (but new commits with new hashes,
> > because the new commit has a different parent than the one on the
> > branch did). That's fine, but it's not a "merge commit".
> >
> >
> > > That basically would somehow record that a series of commits are "related"
> > > (the merge commit has two parents).  Of course usually the merge commit
> > > is empty and thus non-existant but then for branch merges it still
> > > always exists?
> >
> > A merge commit might be empty, but it's not non-existent. But we don't
> > allow merge commits on master, and we don't need to allow them in
> > order to have a series of related commits go in together.
>
> OK, I see.  Guess we should document to not think that a git push
> of a series represented as multiple commits are a "single" commit
> on master

Well yes, because if you push a series of commits then you push ... a
series of commits.

When you push something upstream you make the upstream repo have
exactly the same commits as you have locally. There is no squashing or
flattening involved. The remote repo's HEAD becomes the same commit ID
as your HEAD.

(Before an expert corrects me: strictly speaking, the remote's branch
becomes whatever you push, which doesn't have to be HEAD because you
could do 'git push origin some_commit_hash:master' but in the common
case you just push your HEAD and that becomes the new branch tip on
the remote).


>then and that if you do that individual commits need to be
> bootstrapped and tested.  So, maybe prevent pushes of multiple
> commits for safety?

Please no!


> As for not allowing merges I guess we could eventually relax this
> to allow merge commits that are "empty" and the referred refs
> have linear history from the merge parent?

There's no point. If you have a simple linear history where each
commit has a single parent, there is no merge commit.

I highly recommend this video, to understand the Git model:
https://www.youtube.com/watch?v=1ffBJ4sVUb4
I know it's long, but it's really worth it.

Re: 1-800-GIT-HELP question

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 10:14, Gaius Mulley  wrote:
>
>
> Hello,
>
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
>
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro.  When gcc was using subversion I had a
> script which untared the gm2 git over the subversion, applied local
> patches to the gcc tree and then it was ready for use.  I could git diff
> in the gm2 tree and svn diff in the gcc tree - etc.
>
> I wonder if a similar model can be achieved now gcc uses git?
>
> In essence the gm2 front end adds three subtrees to gcc
>
> libgm2
>
> gcc/m2
>
> gcc/testsuite/gm2
>
> currently these are all in one repro
> gm2/gcc-versionno/{libgm2,gcc/m2,gcc/testsuite/gm2}.
>
> http://git.savannah.gnu.org/cgit/gm2.git/tree
>
> I'm a little cautious of choosing an initial working model without
> knowing the implications.  There seem to be many possible solutions
> (subtree, submodule) to name but two.

Personally I hate submodules, and I've never used subtree. If you need
to make modifications to files in GCC (rather than just adding
completely new dirs) then I don't think submodules would work at all,
I don't know about subtrees.

Is there a reason you can't just make it a branch of the GCC repo?

It would mean you need to merge from upstream GCC into your repo,
rather than just dropping your repo into/onto a GCC clone, but to me
it seems the more natural solution. The modifications to the files in
the GCC tree would also be in your branch (and properly tracked in
git), and so not need to be done manually after untarring gm2 into the
GCC tree.

It would mean your gm2 repo would contain the full GCC history, but
you said disk space isn't a concern. A checkout would need to check
out the full GCC tree as well, but presumably you need some way to
obtain that anyway if you're going to unpack/checkout/whatever the gm2
repo inside the GCC tree.

Re: 1-800-GIT-HELP question

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 11:21, Gaius Mulley  wrote:
>
> Andrew Pinski  writes:
>
> >
> > One thing which you could do is kinda of what glibc did when they
> > merged glibc and glibc-ports.
> > Really it would useful if you get GM2 into the base sources of gcc
> > instead for GCC 11 :).
>
> Hello,
>
> yes indeed this is a huge priority for gm2 - all the big issues are
> resolved now (licensing/gpl3/!libpth).  So I'm really hoping this can be
> achieved,

Great!

That's even more reason to do it as a branch in (your copies of) the
GCC tree then: it will make the process of submitting patches for
inclusion upstream much more straightforward!

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 15:37, Jiang Ma  wrote:
>
> Thanks  for the kindly reply!
> > It would create a non-standard, non-portable dialect of C++. We prefer
> > to avoid adding non-standard extensions these days. You could propose
> >it to the C++ committee, but I'm pretty sure they would not want such
> >a thing.
>   Indeed, pragma is not portable.  I believe you are right that the
> C++ committee would not want such a thing   :-)

I mean they wouldn't want it under any syntax, not just as a pragma.

It's a terrible fit for a pragma anyway.

Re: git conversion in progress

[Jonathan Wakely]

On Thu, 16 Jan 2020 at 09:55, Georg-Johann Lay  wrote:
>
> Am 11.01.20 um 02:18 schrieb Joseph Myers:
> > I encourage people to continue to work on improving the documentation for
> > using git with GCC
>
> Hi, the front page reads "Our sources are readily and freely available
> via SVN...", similar recommendation for SVN in
>
> https://gcc.gnu.org/snapshots.html

Yes, it's been said more than once that the web pages will be updated
once the docs for using git are ready.

Re: Updating "regression hunting" to the Git world (was: [wwwdocs] Adjustments of "regression hunting" instructions to the post-SVN world.)

[Jonathan Wakely]

On Sun, 19 Jan 2020 at 13:07, Gerald Pfeifer wrote:
>
> On Sun, 19 Jan 2020, Gerald Pfeifer wrote (on gcc-patches@):
> > With Git a clone carries the whole repository, so remove instructions
> > on obtaining a local copy of the repository and related instructions
> > on SVN usage.
>
> I just updated https://gcc.gnu.org/bugs/reghunt.html , mostly by
> removing obsolete aspects related to SVN:
>
>https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01121.html
>
>
> If you have further updates to that page, please go ahead and
> simply make them (or let me know).

It still says "The following SVN commands are ..."


> Also contrib/reghunt appears in need of *quite* some updates.
> Or do we want to retire it?

I've never read that web page or looked at contrib/reghunt before, but
most of it can probably be done by 'git bisect' run. The web page
should be rewritten in terms of using git bisect. I can take a stab at
that if nobody else wants to.

It's possible that the various contrib/reghunt/bin/gcc-test-* helper
scripts could still be useful with 'git bisect run' as the building
blocks for a script that checks a given revision.

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

[Jonathan Wakely]

On Tue, 21 Jan 2020 at 16:03, Martin Liška  wrote:
>
> Can you please remove the hook for user branches likes:
>
> $ git push origin me/filter-non-common
> Enumerating objects: 27, done.
> Counting objects: 100% (27/27), done.
> Delta compression using up to 16 threads
> Compressing objects: 100% (14/14), done.
> Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done.
> Total 14 (delta 13), reused 0 (delta 0)
> remote: *** The first line of a commit message should be a short description 
> of the change, not a single word.
> remote: error: hook declined to update 
> refs/users/marxin/heads/filter-non-common
> To git+ssh://gcc.gnu.org/git/gcc.git
>   ! [remote rejected] me/filter-non-common -> 
> refs/users/marxin/heads/filter-non-common (hook declined)
> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'


Requiring slightly better messages than just a single word doesn't
seem to restrictive to me, even on user branches.

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

[Jonathan Wakely]

On Tue, 21 Jan 2020 at 17:06, Jason Merrill  wrote:
>
> On Tue, Jan 21, 2020 at 11:52 AM Richard Earnshaw (lists) <
> richard.earns...@arm.com> wrote:
>
> > On 21/01/2020 16:43, Nathan Sidwell wrote:
> > > On 1/21/20 11:38 AM, Richard Earnshaw (lists) wrote:
> > >> On 21/01/2020 16:14, Jonathan Wakely wrote:
> > >>> On Tue, 21 Jan 2020 at 16:03, Martin Liška  wrote:
> > >>>>
> > >>>> Can you please remove the hook for user branches likes:
> > >>>>
> > >>>> $ git push origin me/filter-non-common
> > >>>> Enumerating objects: 27, done.
> > >>>> Counting objects: 100% (27/27), done.
> > >>>> Delta compression using up to 16 threads
> > >>>> Compressing objects: 100% (14/14), done.
> > >>>> Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done.
> > >>>> Total 14 (delta 13), reused 0 (delta 0)
> > >>>> remote: *** The first line of a commit message should be a short
> > >>>> description of the change, not a single word.
> > >>>> remote: error: hook declined to update
> > >>>> refs/users/marxin/heads/filter-non-common
> > >>>> To git+ssh://gcc.gnu.org/git/gcc.git
> > >>>>! [remote rejected] me/filter-non-common ->
> > >>>> refs/users/marxin/heads/filter-non-common (hook declined)
> > >>>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git
> > '
> > >>>
> > >>> Requiring slightly better messages than just a single word doesn't
> > >>> seem to restrictive to me, even on user branches.
> > >
> > > plus it teaches you good practice in a safe area.
> > >
> > >> I agree.  What's more, if you ever want to merge the branch into trunk
> > >> you'll need to fix such messages, so why not just get them right in
> > >> the first place?
> > >
> > > Are you using 'merge' with some meaning other than git merge?  because
> > > merging to trunk is verboeten.
> >
> > In the sense 'integrate' your change into trunk.  In practice I mean by
> > a fast-forward push, of course.
> >
>
> My commit messages while I'm working on something rarely have anything to
> do with the commit messages that I eventually push to trunk; there's no
> point in writing extensive description of stuff I might discard anyway.
> When I'm done developing a change I then squash and reorganize commits and
> write the commit message for public consumption.

Whether they make it to trunk or not doesn't really change the fact
that a one-word message is poor. If it's only on your local machine,
do what you like. The hook only complains when such a commit is
published on gcc.gnu.org.

Re: GCC Multi-Threading Ideas

[Jonathan Wakely]

On Fri, 24 Jan 2020 at 03:39, Nicholas Krause  wrote:
> Sorry for the second message Allan but make -j does not scale well
> beyond 4 or
> 8 threads and that's considering a 4 core or 8 machine. The problem has to
> do with large build machines with CPUs with more cores than this or as
> is becoming
> more common on mainstream systems.

And make scales well beyond 8 processes (not threads) on such machines.

Re: Merges from release branches to vendor tracking branches

[Jonathan Wakely]

On Thu, 23 Jan 2020 at 23:15, Peter Bergner  wrote:
>
> On 1/23/20 12:09 PM, Peter Bergner wrote:
> > On 1/23/20 4:29 AM, Jakub Jelinek wrote:
> >> so it is not a fast forward merge and we have the requirement that
> >> From-SVN: shouldn't appear in commit logs of new commits.
> >
> > So I just did "git merge releases/gcc-9" into our branch and I'm not
> > seeing any From-SVN: in any of the commit messages.  Where/how are
> > you seeing those?
>
> Actually, I see them now.  I'm not sure what happened before.
>
> So Joseph said these are actually ok on the vendor branches,
> but what was the original concern with them being there in the
> commit logs?

We don't want a commit that has been cherry-picked onto a branch (and
possibly edited to resolve conflicts) to have "From-SVN" in the log,
because that would confuse various scripts into thinking that your new
commit on the branch *is* the commit imported from SVN. If it's a
different commit, it shouldn't have the From-SVN marker from the
original commit.

Only commits  that actually came from SVN should say From-SVN in their logs.

>  Is it still useful to remove them?

If the hooks don't reject it, I'd say no. If the commit really *is* a
merge commit, i.e. you do a 'git merge' to add the same commit with
the original hash to your vendor branch, then it's not useful to
remove them. Because in that case it really *is* the commit that was
imported from SVN (and removing the From-SVN would just alter the
commit and give it a different hash, so now it would be a different
commit, for no good reason).

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

[Jonathan Wakely]

On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote:

On 21/01/2020 18:58, Richard Earnshaw (lists) wrote:
This patch documents some of the scripts that I've published for 
managing the personal and vendor spaces on the server.  It also 
covers some of the other features that those scripts enable, so that 
it's all in one place.  This is a complete rewrite of the material I 
had written previously since before we did not have these scripts to 
make use of.


I've not filled in the documentation for gcc-descr and gcc-undescr, 
Jakub has agreed to provide that at a later date.


R.


I've pushed this.  I think it's better to have this in than nothing at 
all.  We can iterate on it as required.


I've pushed the attached fix for a couple of typos.

Do we want to repeat the "do not push changes to that space without
their express permission" for user branches? There are no access
checks to prevent it, but I hsouldn't be changing things in your
branches without your permission.

Finally, why does this qualify it as "If you have multiple clones"?

If you have multiple clones of the gcc repository you can fetch
updates from your personal space by running
  git fetch me

Isn't that the right command even if you only have one clone?

commit 182ab16b43b0b40b985e0678891b29debef2c9a2
Author: Jonathan Wakely 
Date:   Fri Jan 24 10:59:14 2020 +

Fix typos in gitwrite.html

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index ad073b53..c0fe8526 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -391,7 +391,7 @@ configuration steps can give access to them.
 in refs/vendors/vendor-name/tags.
 
 
-Scripts exist the contrib directory to help manage these spaces.
+Scripts exist in the contrib directory to help manage these spaces.
 
 contrib/gcc-git-customization.sh
 
@@ -413,7 +413,7 @@ some aliases that might be useful when developing GCC.  The script will
 work this out based on the URL used to fetch from the git server, or
 fall back to your local user name if that fails.  Using this name
 on the server for your personal space ensures that your branches will
-not conflict with anybody elses.
+not conflict with anybody else's.
   The prefix to use for your personal branches - the default is
 me, but you can change this if you prefer.  The script
 will add configuration information to allow local branches that

Re: Wrong GCC PR2020 annotated for "[committed, libgomp,amdgcn] Fix plugin-gcn.c bug"

[Jonathan Wakely]

On Thu, 23 Jan 2020 at 16:57, Andrew Stubbs wrote:
> Indeed, PR2019 has a number of unrelated commits referenced, and pr2018
> has one too. The years before that appear to have escaped the problem.

The 2019 ones are even more silly, as the unrelated commits were
correcting the PR number in some filenames!

I'll tag those bugzilla comments as "obsolete" so they're hidden by
default and don't confuse people.

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

[Jonathan Wakely]

On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote:

On 24/01/2020 11:04, Jonathan Wakely wrote:

On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote:

On 21/01/2020 18:58, Richard Earnshaw (lists) wrote:
This patch documents some of the scripts that I've published for 
managing the personal and vendor spaces on the server.  It also 
covers some of the other features that those scripts enable, so 
that it's all in one place.  This is a complete rewrite of the 
material I had written previously since before we did not have 
these scripts to make use of.


I've not filled in the documentation for gcc-descr and 
gcc-undescr, Jakub has agreed to provide that at a later date.


R.


I've pushed this.  I think it's better to have this in than 
nothing at all.  We can iterate on it as required.


I've pushed the attached fix for a couple of typos.

Do we want to repeat the "do not push changes to that space without
their express permission" for user branches? There are no access
checks to prevent it, but I hsouldn't be changing things in your
branches without your permission.



Absolutely.  I guess I took this as read in the personal spaces.


If we don't document it, somebody will get it wrong :-)

Maybe like so, after the "To create a new personal branch" paragraph:

Personal spaces are controlled by the individual user.  Do not push
changes to somebody else's space without their express permission.
(Rather than pushing to somebody else's personal branch, consider pushing
to your own personal branch and having collaborators pull from there).


Is the parenthesis going into too much detail, too early? This page
doesn't describe how to pull from somebody else's personal branch (and
arguably that would be too much info here anyway, but it might make
sense for https://gcc.gnu.org/wiki/GitCookbook instead).

So maybe just the part in .


Finally, why does this qualify it as "If you have multiple clones"?

If you have multiple clones of the gcc repository you can fetch
updates from your personal space by running
  git fetch me

Isn't that the right command even if you only have one clone?




Well, if you only have one clone, why would you need to pull branches 
from upstream that you pushed yourself?


Good point.

In fact, why would you even 
need to push them in that case, unless it's for backup?  ... and if 


So other people can see your work in progress (without the overhead of
setting up a devel/* branch for a short-lived topic branch).

you're restoring your backup, then that's a new clone.  You might 
temporally have only only one clone, but across all time you have more 
than one.


Right. I was stuck in small-minded, non-distributed thinking :-)


It's pedantry, though, so feel free to re-word it.


How about:

"You can fetch updates from your personal space into some other clone
of the repository (e.g. on a machine used for testing) by running:"

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

[Jonathan Wakely]

On 24/01/20 13:55 +, Richard Earnshaw (lists) wrote:

On 24/01/2020 12:19, Jonathan Wakely wrote:

On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote:

On 24/01/2020 11:04, Jonathan Wakely wrote:

On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote:

On 21/01/2020 18:58, Richard Earnshaw (lists) wrote:
This patch documents some of the scripts that I've published 
for managing the personal and vendor spaces on the server.  
It also covers some of the other features that those scripts 
enable, so that it's all in one place.  This is a complete 
rewrite of the material I had written previously since 
before we did not have these scripts to make use of.


I've not filled in the documentation for gcc-descr and 
gcc-undescr, Jakub has agreed to provide that at a later 
date.


R.


I've pushed this.  I think it's better to have this in than 
nothing at all.  We can iterate on it as required.


I've pushed the attached fix for a couple of typos.

Do we want to repeat the "do not push changes to that space without
their express permission" for user branches? There are no access
checks to prevent it, but I hsouldn't be changing things in your
branches without your permission.



Absolutely.  I guess I took this as read in the personal spaces.


If we don't document it, somebody will get it wrong :-)

Maybe like so, after the "To create a new personal branch" paragraph:

Personal spaces are controlled by the individual user.  Do not push
changes to somebody else's space without their express permission.
(Rather than pushing to somebody else's personal branch, consider pushing
to your own personal branch and having collaborators pull from there).


Is the parenthesis going into too much detail, too early? This page
doesn't describe how to pull from somebody else's personal branch (and
arguably that would be too much info here anyway, but it might make
sense for https://gcc.gnu.org/wiki/GitCookbook instead).


I think the 'pull' model is probably preferable for personal spaces.  
At some point we might need to enforce something like that anyway.




So maybe just the part in .


Finally, why does this qualify it as "If you have multiple clones"?

If you have multiple clones of the gcc repository you can fetch
updates from your personal space by running
  git fetch me

Isn't that the right command even if you only have one clone?




Well, if you only have one clone, why would you need to pull 
branches from upstream that you pushed yourself?


Good point.

In fact, why would you even need to push them in that case, unless 
it's for backup?  ... and if


So other people can see your work in progress (without the overhead of
setting up a devel/* branch for a short-lived topic branch).

you're restoring your backup, then that's a new clone.  You might 
temporally have only only one clone, but across all time you have 
more than one.


Right. I was stuck in small-minded, non-distributed thinking :-)


It's pedantry, though, so feel free to re-word it.


How about:

"You can fetch updates from your personal space into some other clone
of the repository (e.g. on a machine used for testing) by running:"




Yes, that's fine.


OK, I've pushed the attached patch.

commit 0bce4cca846fa1d79f080d2784f90aaa5c447e2b
Author: Jonathan Wakely 
Date:   Fri Jan 24 15:00:57 2020 +

Adjust docs on personal Git branches

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index c0fe8526..5b631607 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -424,8 +424,8 @@ some aliases that might be useful when developing GCC.  The script will
 settings configured by the script will still be useful.
 
 
-If you have multiple clones of the gcc repository you can fetch
-updates from your personal space by running
+You can fetch updates from your personal space into some other clone
+of the repository (e.g. on a machine used for testing) by running
   git fetch me
 (or whatever personal prefix you've chosen).  You can also push an
 already existing branch using git push me me/branch.
@@ -444,6 +444,12 @@ used:
 If you've used a different personal prefix to 'me' then use that
   in the sequence described above.
 
+Personal spaces are controlled by the individual user.  Do not push
+changes to somebody else's space without their express permission.
+(Rather than pushing to somebody else's personal branch, consider pushing
+to your own personal branch and having collaborators pull from there.)
+
+
 The script also defines a few useful aliases that can be used with the
 repository:
 

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

[Jonathan Wakely]

On 24/01/20 15:09 +, Jonathan Wakely wrote:

On 24/01/20 13:55 +, Richard Earnshaw (lists) wrote:

On 24/01/2020 12:19, Jonathan Wakely wrote:

On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote:

On 24/01/2020 11:04, Jonathan Wakely wrote:

On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote:

On 21/01/2020 18:58, Richard Earnshaw (lists) wrote:
This patch documents some of the scripts that I've 
published for managing the personal and vendor spaces on 
the server.  It also covers some of the other features 
that those scripts enable, so that it's all in one place.  
This is a complete rewrite of the material I had written 
previously since before we did not have these scripts to 
make use of.


I've not filled in the documentation for gcc-descr and 
gcc-undescr, Jakub has agreed to provide that at a later 
date.


R.


I've pushed this.  I think it's better to have this in than 
nothing at all.  We can iterate on it as required.


I've pushed the attached fix for a couple of typos.

Do we want to repeat the "do not push changes to that space without
their express permission" for user branches? There are no access
checks to prevent it, but I hsouldn't be changing things in your
branches without your permission.



Absolutely.  I guess I took this as read in the personal spaces.


If we don't document it, somebody will get it wrong :-)

Maybe like so, after the "To create a new personal branch" paragraph:

Personal spaces are controlled by the individual user.  Do not push
changes to somebody else's space without their express permission.
(Rather than pushing to somebody else's personal branch, consider pushing
to your own personal branch and having collaborators pull from there).


Is the parenthesis going into too much detail, too early? This page
doesn't describe how to pull from somebody else's personal branch (and
arguably that would be too much info here anyway, but it might make
sense for https://gcc.gnu.org/wiki/GitCookbook instead).


I think the 'pull' model is probably preferable for personal spaces.  
At some point we might need to enforce something like that anyway.




So maybe just the part in .


Finally, why does this qualify it as "If you have multiple clones"?

If you have multiple clones of the gcc repository you can fetch
updates from your personal space by running
  git fetch me

Isn't that the right command even if you only have one clone?




Well, if you only have one clone, why would you need to pull 
branches from upstream that you pushed yourself?


Good point.

In fact, why would you even need to push them in that case, 
unless it's for backup?  ... and if


So other people can see your work in progress (without the overhead of
setting up a devel/* branch for a short-lived topic branch).

you're restoring your backup, then that's a new clone.  You 
might temporally have only only one clone, but across all time 
you have more than one.


Right. I was stuck in small-minded, non-distributed thinking :-)


It's pedantry, though, so feel free to re-word it.


How about:

"You can fetch updates from your personal space into some other clone
of the repository (e.g. on a machine used for testing) by running:"




Yes, that's fine.


OK, I've pushed the attached patch.


Oops, wrong patch, *this* is what I pushed.

commit f526c4724b183482fc7fe1a5ce78e1597fd1005f
Author: Jonathan Wakely 
Date:   Fri Jan 24 15:00:57 2020 +

Adjust docs on personal Git branches

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 55667a2d..b5d7ff35 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -436,6 +436,12 @@ you intend.  The script contrib/git-add-user-branch.sh
 can be used to create a new personal branch which can be pushed and
 pulled from the users/me remote.
 
+Personal spaces are controlled by the individual user.  Do not push
+changes to somebody else's space without their express permission.
+(Rather than pushing to somebody else's personal branch, consider pushing
+to your own personal branch and having collaborators pull from there.)
+
+
 The script also defines a few useful aliases that can be used with the
 repository:
 

Re: SSA Iterators

[Jonathan Wakely]

On Thu, 30 Jan 2020, 05:44 Nicholas Krause wrote:
>
> Greetings,
>
> I was looking into starting to cleaning up the SSA trees for various
> reasons and iterators
> seem to be the easiest to do. I searched the list to see if someone
> mentioned it before
> and I ran across this:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02031.html
>
> If your trying to get a second ++ working then why not override it
> prefix as your
> just doing it for postfix and those can be separate.

No no no.

No.

> Its not ideal to
> have two
> different versions for prefix and postfix in terms of overloading but it
> may be
> the simplest solution here.

No, making pre-increment and post-incrememt so different things (i.e.
iterate over different ranges) is a horrible idea. That's the kind of
thing that gives operator overloading a bad name. Overloaded operators
should do the thing you expect them to. They should not be used to
hide a non-obvious action behind an apparently simple syntax.


I would suggest avoiding "smart" iterators that contain all the state
and know their own end point. Instead create a type that holds all the
state and has begin/end member functions which return an iterator that
refers to the state. And have the iterator  dereference to some other
object that has the state for the second level of iteration, with its
own begin/end members returning the second iterator type. That would
end up looking like:

  imm_use_stmt_range r (SSAVAR);
  for (imm_use_stmt_iter it = r.begin (); it != r.end (); ++it)
for (imm_use_on_stmt_iter it2 = it->begin (); it2 != it->end (); ++it2)
  ;

At some point when we move to C++11 or later that could become:

  imm_use_stmt_range r (SSAVAR);
  for (auto& stmt : r)
for (auto& on_stmt : *stmt)
  ;

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

[Jonathan Wakely]

On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote:
> Where does your '50 chars' limit come from?  It's not in the glibc text,
> and it's not in the linux kernel text either.  AFAICT this is your
> invention and you seem to be the only person proposing it.

It's a fairly well established convention, e.g.
https://chris.beams.io/posts/git-commit/ and it's what Github suggests
(and whines if you go past it).

> I think the linux rule (the whole line, not including the parts that are
> removed on commit, should not exceed 75 characters) is far more sensible
> - which is why this draft states this.

I'm OK with that.

Re: Git ChangeLog policy for GCC Testsuite inquiry

[Jonathan Wakely]

On Thu, 6 Feb 2020 at 14:01, Richard Biener wrote:
> So do you have a script that takes a commit with a ChangeLog at its end
> and populates the appropriate ChangeLog files?  I'm trying to come up with
> one to make the process less manual ... it's definitely a part that requires
> more typing compared to svn.  ChangeLog file populating could be even
> done on the server-side I guess (and not appropriately formatted logs
> for the extraction/moving process rejected).

I have a script that does the opposite, which I've been using for
years. I edit the ChangeLog files as before, and a Git
prepare-commit-msg hook extracts the top changelog entry from each
file in the commit and pre-populates my commit msg with those entries.

To use it just put the two prepare-commit-msg* files from
https://gitlab.com/miscripts/miscripts/-/tree/master/gcc into your
$GCC_SRC/.git/hooks directory.

Re: C++ 20

[Jonathan Wakely]

On Thu, 6 Feb 2020 at 15:50, Paul Deitel wrote:
>
> Hi,
>
> Is there a docker container for the current development version of GCC 10?

This question would be more appropriate on the gcc-help mailing list.

The GCC project doesn't provide pre-built binaries or packages of any kind.

The rawhide image at https://hub.docker.com/_/fedora has GCC 10.

Or you can install the .deb file from
https://jwakely.github.io/pkg-gcc-latest/ in an Ubuntu container.

Re: Git ChangeLog policy for GCC Testsuite inquiry

[Jonathan Wakely]

On Fri, 7 Feb 2020 at 09:20, Richard Biener  wrote:
>
> On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool
>  wrote:
> > Instead of "git am" I had "patch -p1 <", distributing the changelog parts
> > I just did in vi (as with git), then "svn ci", which pick up all modified
> > files directly (sometimes an "svn add" first).  It's pretty much the same
> > for me.
>
> I'm a believer on committing from the tree I actually tested, so it

With Git you can't really have unwanted local commits present in a
tree if you use a sensible workflow, so if you tested in a tree that
was at commit 1234abcd and you push from another machine that is at
the same commit, you know there are no unintended differences.

> was with SVN: patch, test, svn up, edit changelogs (cut&paste from the
> patch header), svn diff | less (check wha'ts abotu to be committed), svn 
> commit
> with GIT its now: patch, test, git add/commit,

There is no good reason to delay add+commit until after testing.

Committing locally is a completely different operation from committing
to svn, because nothing is "final" until you push to gcc.gnu.org. I
commit locally, and then either test locally or push to larger
machines where I test, or test in both places at once. Even if you
only work on one machine, keeping uncommitted changes around is error
prone (it's easier to lose the work, it's easier to not realise
exactly what you're testing, it's harder to verify that what you
tested is what you eventually pushed).

Applying somebody else's patch to test it can be done in a local
branch and committed locally. You can always delete that branch later
to clear up (a naming convention like "patch-20200207-foo-bar" helps
to keep those branches clearly labelled so you can easily decide which
to remove later).

Once you've committed something it has a commit hash to identify it,
so you can easily compare the state at that revision to some other
revision, at any later time.

tl;dr make more use of branches.

Re: Git ChangeLog policy for GCC Testsuite inquiry

[Jonathan Wakely]

On Sat, 8 Feb 2020 at 19:58, Segher Boessenkool
 wrote:
>
> On Sat, Feb 08, 2020 at 09:46:53AM +1030, Alan Modra wrote:
> > On Fri, Feb 07, 2020 at 10:08:25AM +0000, Jonathan Wakely wrote:
> > > With Git you can't really have unwanted local commits present in a
> > > tree if you use a sensible workflow, so if you tested in a tree that
> > > was at commit 1234abcd and you push from another machine that is at
> > > the same commit, you know there are no unintended differences.
> >
> > Maybe I don't have a sensible workflow, but often with lots of tiddly
> > little binutils patches I don't bother with branches for everything.
>
> Yup, same here.  And I sometimes "git revert" some of the patches I have
> in my "work" tree to be able to test other patches, while making it easy
> to get things back.  To prevent "death by a thousand branches" syndrome.
> Apparently you can do similar with "git stash", but I never got the hang
> of that.
>
> Sometimes I revert a revert of a revert.  That's probably too much
> though :-)

My main point was that Richi should be committing things, not working
with uncommitted patches hanging around making things dirty.

I like to use branches, but having a single branch with a series of
commits that you reorder and selectively push is still better than
uncommitted work.

Re: Eagerly evaluate __atomic_is_lock_free to 0 for oversized types

[Jonathan Wakely]

On Tue, 11 Feb 2020 at 04:34, Fangrui Song  wrote:
>
> GCC never evaluates __atomic_is_lock_free to 0. 
> (gcc/builtins.c:fold_builtin_atomic_always_lock_free)
> I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for 
> apparently oversized types.
> This helps some platforms to avoid a dependency on libatomic.
>
> Either of the following choices can move my patch 
> https://reviews.llvm.org/D72579 forward:
>
> * GCC will like do the same
> * GCC is committed to not extend __atomic_is_lock_free in a clang 
> incompatible way.

We discussed this on IRC in #gcc. There was no motivation to change
GCC. The platform that wants to avoid the libatomic dependency doesn't
use GCC anyway. Relying on not getting the libatomic dependency seems
fragile (it only works for a specific codebase, and if some other
is_lock_free check is added to the codebase, the libatomic dependency
will return anyway).

Re: update github gcc mirror forks to the new repo?

[Jonathan Wakely]

On Tue, 18 Feb 2020 at 06:38, Dennis Luehring wrote:
>
> so the github gcc mirror is already using the new reposurgeon based git
> repo,
>
> that means that all the commit hashes etc. are different if someone
> forked this gcc mirror
>
> so easy pulling from the mirror isn't possible anymore - or am im wrong?
>
>
> is there any description how to "port" over github projects that
> dependens on the old repo?
>
> would a simple rebase work, or cherry picking?

You can use rebasing or cherry-picking, but you need to do so
carefully. If you try to rebase (or cherry-pick) onto the tip of a
branch in the new repo you'll almost certainly get conflicts, because
the new branch in the new repo has moved on since the point where you
last pulled from the old repo.

The best way is to find the commit in the new repo which corresponds
to the last commit you have from the old repo, and rebase onto that.
That way you can graft your local commits onto exactly the same tree
(but with different hashes and different history) which should apply
cleanly.

There's a script to do that at
https://gcc.gnu.org/ml/gcc/2020-01/msg00202.html (and an alternative
in the reply to that email).

To use the script you need to have set up a remote for the old repo
(which you can remove again later if you want):

git remote add gcc-old git://gcc.gnu.org/git/gcc-old.git
git fetch gcc-old






>
> thx
>
>

Re: ABI compatibility: GCC9 vs GCC10

[Jonathan Wakely]

On Fri, 21 Feb 2020 at 05:57, Jason Mancini wrote:
>
> Any notable ABI changes from 9 to 10?

Any such changes will be documented at https://gcc.gnu.org/gcc-10/changes.html

Re: Hey, spotted an out-of-date reference on gcc.gnu.org

[Jonathan Wakely]

You keep talking about a broken link without telling us where it is.

But I don't think we're interested anyway, that's why nobody has replied.



On Mon, 24 Feb 2020 at 12:24, Richard @ Quality Nonsense PR Team
 wrote:
>
> Dear GCC Team,
>
> Just checking in one last time to make sure we don't get overlooked in your 
> inbox.
>
> Is there anything stopping you from recommending our  long read about Digital 
> Equipment Corporation to your users instead of the broken DEC link, out of 
> interest?
>
> I'm always interested in actionable feedback ;)
>
> Richard
> Digital.com
>
> On Wed, Feb 19, 2020 at 11:34 AM, Richard @ Quality Nonsense PR Team 
>  wrote:
>
> Dear GCC Team,
>
> I'm following up to make sure you didn't miss my email about your broken link 
> to DEC.com. What did you think about my idea of citing our long read about 
> Digital Equipment Corporation instead? Can I answer any questions, perhaps?
>
> Richard
> Digital.com
>
> On Thu, Feb 13, 2020 at 12:25 PM, Richard @ Quality Nonsense PR Team 
>  wrote:
>
> Dear GCC Team,
>
> I’m writing because you cite DEC.com in this post on GCC - but the website 
> has been offline for 5+ years!
>
> At Digital.com, we've published a "long read" on the rise and fall of Digital 
> Equipment Corporation, which I thought make an "easy fix" to send your 
> readers somewhere more useful than a 404 page.
>
> It covers everything from VAX, Altavista, DEC's sale to Compaq & ultimate 
> demise. You'll find the article here:-
>
> https://digital.com/about/dec/
>
> Would you consider citing our work to replace the broken DEC.com link, please?
>
> I think this article would keep your content current and your readers happy - 
> love to hear what you think. Either way, thank you for your time and 
> consideration.
>
> Best wishes,
>
> Richard
> Digital.com
> Don't want emails from us anymore? Reply to this email with the word 
> "UNSUBSCRIBE" in the subject line.
> Digital.com, BM Box 3667 , London, Greater London, WC1N 3XX , United Kingdom
> If you don't want further emails from me, please reply with 
> "UNSUBSCRIBE" in the subject line. Thank you.
>
> Digital.com, BM Box 3667, BM Box 3667 Greater London, WC1N 3XX , United 
> Kingdom
> If you don't want further emails from me, please reply with 
> "UNSUBSCRIBE" in the subject line. Thank you.
>
> Digital.com, BM Box 3667, BM Box 3667 Greater London, WC1N 3XX , United 
> Kingdom

Re: GCC Bugzilla (and other) timeouts

[Jonathan Wakely]

On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote:
>
> Bugzilla has been slow lately, and today to the point of timing out
> (I see the same problem with Git).  This seems to be a recurring theme
> around the time of a GCC release.  Is anyone else experiencing this
> problem and if so, does anyone know what the cause it and an ETA for
> a solution?  Is the upcoming hardware upgrade expected to solve it?
>
> Thanks
> Martin
>
> $ git pull
> Connection closed by 209.132.180.131 port 22
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.

What URL are you using to pull? (git remote get-url origin)

Bugzilla and httpd are very slow, but I haven't had any git timeouts.
If you're using anonymous access that gets throttled more aggressively
than authenticated access (using git+ssh:// for the protocol).

Re: GCC Bugzilla (and other) timeouts

[Jonathan Wakely]

On Wed, 26 Feb 2020 at 14:42, Jason Merrill  wrote:
>
> On Wed, Feb 26, 2020 at 3:39 AM Jonathan Wakely  wrote:
>>
>> On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote:
>> >
>> > Bugzilla has been slow lately, and today to the point of timing out
>> > (I see the same problem with Git).  This seems to be a recurring theme
>> > around the time of a GCC release.  Is anyone else experiencing this
>> > problem and if so, does anyone know what the cause it and an ETA for
>> > a solution?  Is the upcoming hardware upgrade expected to solve it?
>> >
>> > Thanks
>> > Martin
>> >
>> > $ git pull
>> > Connection closed by 209.132.180.131 port 22
>> > fatal: Could not read from remote repository.
>> >
>> > Please make sure you have the correct access rights
>> > and the repository exists.
>>
>> What URL are you using to pull? (git remote get-url origin)
>>
>> Bugzilla and httpd are very slow, but I haven't had any git timeouts.
>> If you're using anonymous access that gets throttled more aggressively
>> than authenticated access (using git+ssh:// for the protocol).
>
>
> Yes, I used to use git:// for pulls and ssh:// for pushes, but switched to 
> ssh:// for both because I was getting too many rejected connections.

Another trick I use to improve round trip time of git operations is to
use an ssh control path, see ControlMaster in man 5 ssh_config.

In my ~/.ssh/config I have:

Host gcc.gnu.org
  User redi
  Protocol 2
  ForwardX11 no
  ForwardAgent no
  Compression yes
  # instead of ControlMaster=auto you can open a master connection
with ssh -M -N -f r...@gcc.gnu.org
  ControlMaster auto
  # OpenSSH 5.6 and later:
  ControlPersist yes
  ControlPath /tmp/ssh_%h

This keeps a persistent connection open to the server which gets
reused every time I connect over ssh. The downside is that sometimes
after a network change the control path gets stuck and needs to be
manually closed with 'ssh -O exit gcc.gnu.org' (it will get
automatically recreated by the next ssh connection or git fetch/push).

Re: issue with GDB python pretty-printers for libstdc++

[Jonathan Wakely]

On Wed, 26 Feb 2020 at 14:32, Paul Smith  wrote:
>
> Hi all.  I was seeing a strange error in GDB (8.2.1) debugging some C++
> code while trying to print a value.  The pretty printer was throwing Python
> exceptions.
>
> Debugging it I discovered the problem, which is here (from GCC 9.2):
>
> libstdc++-v3/python/libstdcxx/v6/printers.py:
>   # Starting with the type ORIG, search for the member type NAME.  This
>   # handles searching upward through superclasses.  This is needed to
>   # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615.
>   def find_type(orig, name):
>   typ = orig.strip_typedefs()
>   while True:
>   # Strip cv-qualifiers.  PR 67440.
> -->   search = '%s::%s' % (typ.unqualified(), name)
>   try:
>   return gdb.lookup_type(search)
>   except RuntimeError:
>   pass
>   # The type was not found, so try the superclass.  We only need
>   # to check the first superclass, so we don't bother with
>   # anything fancier here.
>   field = typ.fields()[0]
>
> (First that GDB bug was fixed in 2012 so I'm not sure if we still need this
> method, but anyway...)
>
> The issue is on the marked line above.  Here we are using the __str__()
> method on a gdb.Type to obtain the string name of the type.  However, I've
> discovered that (at least on my system) the __str__() representation of a
> gdb.Type prepends the keyword "class " or "struct " (as appropriate) to the
> output.  So the above will result in a string like:
>
>   search = 'class std::unordered_map...::...'

I don't think I've seen that problem before. Are you sure that's the
cause, and not something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 ?


> The prepended "class " causes the code to break: it doesn't find the type,
> then we try to use typ.fields()[0] which doesn't work as follows:
>
>   Traceback (most recent call last):
>   ...
> File "/cc/python/libstdcxx/v6/printers.py", line 97, in find_type
>   field = typ.fields()[0]
>   IndexError: list index out of range
>
> I think that it's not correct for the Python macros here to be using the
> gdb.Type.__str__() method to obtain the type name for anything other than
> displaying to users.  They should always be using the gdb.Type.name data
> member instead.  If I change the marked line above to be:
>
>   search = '%s::%s' % (typ.unqualified().name, name)
>
> then it all works as expected.
>
> However, I took a quick look through the code and it _appears_ to me that
> this type of thing (using the implied, or explicit, gdb.Type.__str__() to
> obtain the type name) is done in a number of places.

I'm never clear whether we should be using Type.name or Type.tag or
Type.__str__() because they all seem to do the wrong thing in
different situations.

> This makes me wonder whether (a) for some reason no one noticed this
> before, or (b) there's something bizarre about my GDB which is prepending
> this "class" or "struct" where other peoples' don't do that?

Re: issue with GDB python pretty-printers for libstdc++

[Jonathan Wakely]

On Wed, 26 Feb 2020 at 17:01, Jonathan Wakely  wrote:
>
> On Wed, 26 Feb 2020 at 14:32, Paul Smith  wrote:
> >
> > Hi all.  I was seeing a strange error in GDB (8.2.1) debugging some C++
> > code while trying to print a value.  The pretty printer was throwing Python
> > exceptions.
> >
> > Debugging it I discovered the problem, which is here (from GCC 9.2):
> >
> > libstdc++-v3/python/libstdcxx/v6/printers.py:
> >   # Starting with the type ORIG, search for the member type NAME.  This
> >   # handles searching upward through superclasses.  This is needed to
> >   # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615.
> >   def find_type(orig, name):
> >   typ = orig.strip_typedefs()
> >   while True:
> >   # Strip cv-qualifiers.  PR 67440.
> > -->   search = '%s::%s' % (typ.unqualified(), name)
> >   try:
> >   return gdb.lookup_type(search)
> >   except RuntimeError:
> >   pass
> >   # The type was not found, so try the superclass.  We only need
> >   # to check the first superclass, so we don't bother with
> >   # anything fancier here.
> >   field = typ.fields()[0]
> >
> > (First that GDB bug was fixed in 2012 so I'm not sure if we still need this
> > method, but anyway...)
> >
> > The issue is on the marked line above.  Here we are using the __str__()
> > method on a gdb.Type to obtain the string name of the type.  However, I've
> > discovered that (at least on my system) the __str__() representation of a
> > gdb.Type prepends the keyword "class " or "struct " (as appropriate) to the
> > output.  So the above will result in a string like:
> >
> >   search = 'class std::unordered_map...::...'
>
> I don't think I've seen that problem before. Are you sure that's the
> cause, and not something like
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 ?

I compiled this program:

#include 

int main()
{
  std::unordered_map m;
  m[3] = 5;
  return m[1];
}

And with Fedora 31's GDB 8.3.50 I get this behaviour:

(gdb) py m = gdb.parse_and_eval('m')
(gdb) py print(m.type)
std::unordered_map, std::equal_to,
std::allocator > >
(gdb) py print(str(m.type))
std::unordered_map, std::equal_to,
std::allocator > >

There's no 'class' being added. But I also tried changing the
printers.py script to use .name and all our tests still pass, so I'm
not opposed to that change.

Re: Binaries page modifications

[Jonathan Wakely]

On 27/02/20 08:23 +, CHIGOT, CLEMENT wrote:

Hi everyone,

I'm one of the owner of the BullFreeware website and I'm seeing that, in 
https://gcc.gnu.org/install/binaries.html, our website is described for "Bull’s Open Source 
Software Archive for for AIX 5L and AIX 6;". Would it be possible to change it for 
"Bull’s Open Source Software Archive for AIX 6 and AIX 7;", as we're no longer working on 
AIX5 ?


Thanks for the mail. I've made that change with this patch, committed
to master as obvious.

By the way, I noticed that the "About" text on the front page of
bullfreeware.com says "appplication".


commit 4fd9efc8877814e8cda506563d0282a267c562c8
Author: Jonathan Wakely 
Date:   Thu Feb 27 08:42:05 2020 +

doc: Update description of BullFreeware

* doc/install.texi (Binaries): Update description of BullFreeware.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 9b24a06d961..92961833ef6 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3274,7 +3274,7 @@ AIX:
 @itemize
 @item
 @uref{http://www.bullfreeware.com,,Bull's Open Source Software Archive for
-for AIX 5L and AIX 6};
+for AIX 6 and AIX 7};
 
 @item
 @uref{http://www.perzl.org/aix/,,AIX Open Source Packages (AIX5L AIX 6.1

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Jonathan Wakely]

On Thu, 27 Feb 2020 at 06:50, Nicholas Krause  wrote:
>
> Greetings Martin,
>
> This patch:
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06
>
> May have a small problem with the lines:
> +  const char *makeflags = getenv ("MAKEFLAGS");
> +  if (makeflags == NULL)
> +return false; I'm not sure if ninja or other build systems use that
> for detection or have it as a variable you can use. This may be an issue
> with ninja, cmake and other build systems that may not have it. Maybe
> I'm wrong but it may be good to check that, Nick

The patch is to use Make's jobserver, it's not expected to work with
arbitrary build systems.

Martin, the comment in your patch says "-std=c11" which should be c++11.

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Jonathan Wakely]

On Thu, 27 Feb 2020 at 16:18, Nicholas Krause  wrote:
>
>
>
> On 2/27/20 3:44 AM, Jonathan Wakely wrote:
> > On Thu, 27 Feb 2020 at 06:50, Nicholas Krause  wrote:
> >> Greetings Martin,
> >>
> >> This patch:
> >> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06
> >>
> >> May have a small problem with the lines:
> >> +  const char *makeflags = getenv ("MAKEFLAGS");
> >> +  if (makeflags == NULL)
> >> +return false; I'm not sure if ninja or other build systems use that
> >> for detection or have it as a variable you can use. This may be an issue
> >> with ninja, cmake and other build systems that may not have it. Maybe
> >> I'm wrong but it may be good to check that, Nick
> > The patch is to use Make's jobserver, it's not expected to work with
> > arbitrary build systems.
> >
> > Martin, the comment in your patch says "-std=c11" which should be c++11.
>
> Jonathan,
>
> That's a problem then as were assuming a user's build system for this to
> work. I mean
> for now its fine but in the future wouldn't it de a good ideal to not
> assume this?

It works fine for everybody. There's just an optimisation for people
with a GNU make jobserver available. I don't see a problem.

If somebody wants to add an optimisation for their preferred build
system they can propose a patch.

Re: what is the post price of this sites?https://gcc.gnu.org/

[Jonathan Wakely]

On 28/02/20 19:34 +1300, maticulous wrote:

I can assure you that the website @gnu.org or any domains associated with
gnu.org are not for sale.
If you want to negotiate you should probably contact GNU directly.


They're not trying to buy the domain, they're asking what we charge
for somebody to post their stupid, spammy, SEO-junk articles on our
website.

Obviously we don't let idiot spammers post articles on our site, but
they're idiots and don't understand that.

You should read https://gcc.gnu.org/spam.html though.

Re: Status of C++11 Move and Using Unique_Ptr

[Jonathan Wakely]

On Sun, 1 Mar 2020 at 20:24, Nicholas Krause wrote:
> I'm not sure of the current status of the C++11
> move

We're in the middle of GCC 10's stage 4 and not doing anything like that now.

As has been said several times, it's in scope for GCC 11, but not before.

Re: Fwd: Legal Prerequisites contributions

[Jonathan Wakely]

On 01/03/20 14:37 +0100, Michael de Lang wrote:

Dear Sir/Madam,

I'm working on implementing pr0980r1 and people in the #gcc channel
told me to get the legal process started asap. I am willing to sign
copyright assignments as outlayed on
https://gcc.gnu.org/contribute.html

Met vriendelijke groet,
Michael de Lang


Form sent offlist.