Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Joern Rennecke]

Quoting Stefano Lattarini :


By looking at the 'handle_texinfo_helper' function in the automake script,
I suspect adding a new Automake option 'info-in-builddir' (say) and an
handful of lines to the automake script might be enough to give you an easy
way to force the '.info' files to be generated in the builddir.  But before
doing so, I'd like to understand why you want so strongly to support such
a setup.


It is quite common during development / testing to build multiple
configurations simultaneously from the same sources, with separate
make processes.  Writing to the source directory would cause disastrous
race conditions.

Re: Why can't copy renaming capture this assignment?

[Richard Guenther]

2012/4/3 Jiangning Liu :
>
> 在 2012-4-2 下午4:37，"Richard Guenther" 写道：
>
>
>>
>> On Sat, Mar 31, 2012 at 6:23 AM, Jiangning Liu 
>> wrote:
>> > Hi,
>> >
>> > For this small case,
>> >
>> > char garr[100];
>> > void f(void)
>> > {
>> >unsigned short h, s;
>> >
>> >s = 20;
>> >
>> >for (h = 1; h < (s-1); h++)
>> >{
>> >garr[h] = 0;
>> >}
>> > }
>> >
>> > After copyrename3, we have the following dump,
>> >
>> > f ()
>> > {
>> >  short unsigned int h;
>> >  int D.4066;
>> >
>> > :
>> >  D.4066_14 = 1;
>> >  if (D.4066_14 <= 18)
>> >goto ;
>> >  else
>> >goto ;
>> >
>> > :
>> >  # h_15 = PHI 
>> >  # D.4066_16 = PHI 
>> >  garr[D.4066_16] = 0;
>> >  h_8 = h_15 + 1;
>> >  D.4066_4 = (int) h_8;
>> >  if (D.4066_4 <= 18)
>> >goto ;
>> >  else
>> >goto ;
>> >
>> > :
>> >  return;
>> >
>> > }
>> >
>> > copy renaming fails to capture the assignment statement "D.4066_4 =
>> > (int)
>> > h_8;" to trigger renaming partition coalesce.
>> >
>> > I find gimple_assign_single_p invoked by gimple_assign_ssa_name_copy_p
>> > always returns false, because for this statement " gs->gsbase.subcode"
>> > is
>> > NOP_EXPR rather than GIMPLE_SINGLE_RHS.
>> >
>> > Should subcode be correctly initialized anywhere to fix this problem?
>> >
>> > BTW, my expectation after copy renaming is like below,
>> >
>> > f ()
>> > {
>> >  int D.4679;
>> >
>> > :
>> >  D.4679_7 = 1;
>> >  if (D.4679_7 != 19)
>> >goto ;
>> >  else
>> >goto ;
>> >
>> > :
>> >  # D.4679_15 = PHI 
>> >  # D.4679_17 = PHI 
>> >  garr[D.4679_15] = 0;
>> >  D.4679_14 = D.4679_17 + 1;
>> >  D.4679_4 = D.4679_14;
>> >  if (D.4679_4 != 19)
>> >goto ;
>> >  else
>> >goto ;
>> >
>> > :
>> >  return;
>> >
>> > }
>>
>> Err - you completely lost the fact that h was short instead of int.
>>
>> Richard.
>>
>> > and then PRE can finally remove that redundancy for symbol D. away.
>
> Hi Richard,
>
> Well, actually I noticed that, but which optimization would be able to
> handle this case and finally get that redundancy removed, if copy renaming
> can't detect this? It's quite obviouse that h and D. contain the same
> data, right? Or are you implying we should neither generate an integer type
> of temp variable D. nor generate this temp variable in previouse pass at
> all?

They don't contain the same 'data' (their data has different size).  They
contain the same value.  If you want to get rid of either you have to get
rid of, or rewrite, all uses of either.  In this case

:
 D.4066_14 = 1;
 if (D.4066_14 <= 18)
   goto ;
 else
   goto ;

:
 # h_15 = PHI 
 # D.4066_16 = PHI 
 garr[D.4066_16] = 0;
 h_8 = h_15 + 1;
 D.4066_4 = (int) h_8;
 if (D.4066_4 <= 18)
   goto ;
 else
   goto ;

:
 return;

you'd want to use h_8 in the comparison.  forwprop would do this if
there were a single use only of D.4066_4 (well, I suppose it would, it
at least seems not to do this if there is the PHI node around).  The
PHI node is harder - the type used in the array indexing does not
really matter, so using h_8 would be ok there, but you would need to
rewrite the PHI node.  You can _not_ rewrite the h_8 definition to
use D.4066 and type 'int' because overflow on that would be undefined
while h may wrap just fine (well, at least not without value-range analysis).

So.  I suppose the right pass to handle the above is a combination
of value-numbering and value-range analysis - you have to prove
equality of h and D.4066 which is not mapping to either exactly
because of the differing types.  I suppose VN could be relaxed
in its type compatibility requirements (but that would be a pretty
disrupting change) and value-number D.4066_4 equal to h_8.  Eliminating
the redundancy then would have to cope with the type incompatibility
and decide that h_8 is the one to keep (because we can't rewrite the
addition).

So I suppose for this specific case a pass that performs type promotion/demotion
(as was discussed repeatedly) would be a better thing, and an enablement
of trivial redundancy removal.

Richard.

>
> Thanks,
> ~Jiangning
>
>> >
>> > Thanks,
>> > -Jiangning
>> >
>> >
>> >
>> >
>> >

Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)

[Richard Guenther]

On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm  wrote:
> I wrote a script and ported my proposed API for GCC plugins from my
> CamelCase naming convention to an underscore_based_convention (and
> manually fixed up things in a few places also).
>
> The result compiles and passes the full test suite for the Python
> plugin; that said, I'm still breaking the encapsulation in quite a few
> places (hey, this is an experimental prototype).
>
> You can see the latest version of it within the "proposed-plugin-api"
> branch of the Python plugin here:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api
>
> within the "proposed-plugin-api" subdirectory.

Hmm, how do I get it?  I did

git clone http://git.fedorahosted.org/git/proposed-plugin-api

but there is nothing in gcc-python-plugin/.  And

git checkout proposed-plugin-api

says I'm already there ...?

Richard.

> How is this looking?
>
> If this landed e.g. in GCC 4.8, would this be usable by other plugins?
>
> Hope this is helpful
> Dave
>

Re: compiling gcc 2.95.3 under ubuntu 10.04.2, x86_64

[Andrew Haley]

On 04/02/2012 06:29 PM, Roman Suvorov wrote:
> Hello everyone,
> Not sure if this is the right place to ask this question, feel free to point 
> me in the right direction.

Redirect to gcc-help.

> I'm looking into the evolution of Linux kernel and this requires me
> to build some ancient releases (as old as 2.4.0) from source using
> GCC. I have gcc 4.4.3-4ubuntu5 installed on my lab machine but it's
> incompatible with these old sources, and the "lowest common
> denominator" would be gcc 2.95.3, so I've been trying to compile it
> from source - so far with little success.

> It's hard but not impossible - done before by this guy:
> http://www.trevorpounds.com/blog/?p=111&cpage=1#comment-102. I
> followed all of his suggestions but so far hasn't had much luck -
> most recent attempt dies with the following message:

> /usr/bin/ld.bfd.real: error in pic/cstrmain.o(.eh_frame); no .eh_frame_hdr 
> table will be created.
> 
> The URL above contains a link to my stdout/stderr logs too. Has anyone here 
> tried compiling such an old version of GCC? Any advice/help would be greatly 
> appreciated.

It's going to be hard.  gcc 2.95 doesn't support using x86_64 as a host,
so you're going to have to build in in a 32-bit virtual machine or by
using mock.

You'll have other problems too.  gcc back then wasn't so standards-
clean as it is now; we have a lot of warnings and better diagnostics
that have allowed us to clean up gcc.  I don't know why you got that
particular message, and as I said I can't look at your logs.  I might
have a try myself to build gcc 2.95 later today.

Andrew.

Re: compiling gcc 2.95.3 under ubuntu 10.04.2, x86_64

[Richard Guenther]

On Tue, Apr 3, 2012 at 12:21 PM, Andrew Haley  wrote:
> On 04/02/2012 06:29 PM, Roman Suvorov wrote:
>> Hello everyone,
>> Not sure if this is the right place to ask this question, feel free to point 
>> me in the right direction.
>
> Redirect to gcc-help.
>
>> I'm looking into the evolution of Linux kernel and this requires me
>> to build some ancient releases (as old as 2.4.0) from source using
>> GCC. I have gcc 4.4.3-4ubuntu5 installed on my lab machine but it's
>> incompatible with these old sources, and the "lowest common
>> denominator" would be gcc 2.95.3, so I've been trying to compile it
>> from source - so far with little success.
>
>> It's hard but not impossible - done before by this guy:
>> http://www.trevorpounds.com/blog/?p=111&cpage=1#comment-102. I
>> followed all of his suggestions but so far hasn't had much luck -
>> most recent attempt dies with the following message:
>
>> /usr/bin/ld.bfd.real: error in pic/cstrmain.o(.eh_frame); no .eh_frame_hdr 
>> table will be created.
>>
>> The URL above contains a link to my stdout/stderr logs too. Has anyone here 
>> tried compiling such an old version of GCC? Any advice/help would be greatly 
>> appreciated.
>
> It's going to be hard.  gcc 2.95 doesn't support using x86_64 as a host,
> so you're going to have to build in in a 32-bit virtual machine or by
> using mock.
>
> You'll have other problems too.  gcc back then wasn't so standards-
> clean as it is now; we have a lot of warnings and better diagnostics
> that have allowed us to clean up gcc.  I don't know why you got that
> particular message, and as I said I can't look at your logs.  I might
> have a try myself to build gcc 2.95 later today.

You can have success with only minor patching when you stage a 3.x
release inbetween and use that to compile 2.95.  At least that is how
I created my 2.95 build ;)

Richard.

> Andrew.

Re: unwind and type support in GCC47

[Paulo J. Matos]

On 30/03/12 05:11, Ian Lance Taylor wrote:

"Paulo J. Matos"  writes:


I am porting my backend to GCC47 and have been jumping through some
hurdles. libgcc is trying to compile unwind*.c files which I can't
remember being there for GCC46.


They were there.  In 4.6 they were in the gcc subdirectory.  For 4.7
they moved to the libgcc directory.  This was a logical move because
they have always been part of libgcc, not part of the compiler (and
enormous thanks for Rainer Orth for working through the mechanics of
moving them.)



You are right, they were but they were not being compiled for my target. 
The reason they were being compiled for GCC47 is my fault and a problem 
with way I moved config files accross.



or to
make unwind compatible with my backend besides going blindly changing SI
mode in variable declaration to QI mode?


There really shouldn't be anything in the exception support that uses
SImode.  That would be a bug.  And I don't see anything that uses
SImode.  What are you looking at?  What I see is things that use mode
__unwind_word__, __word__, and __pointer__.  Those types are under the
control of your backend.



I was mentioning these references to SI:
unwind-pe.h:
static const unsigned char *
read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
  const unsigned char *p, _Unwind_Ptr *val)
{
  union unaligned
{
  void *ptr;
  unsigned u2 __attribute__ ((mode (HI)));
  unsigned u4 __attribute__ ((mode (SI)));
  unsigned u8 __attribute__ ((mode (DI)));
  signed s2 __attribute__ ((mode (HI)));
  signed s4 __attribute__ ((mode (SI)));
  signed s8 __attribute__ ((mode (DI)));
} __attribute__((__packed__));
...


There are also some references to mode SI in unwind-dw2.c.

And there's also this:
unwind-dw2-fde.h:typedef  int  sword __attribute__ ((mode (SI)));

Why hardcode these type sizes here? 

Cheers,

--
PMatos

Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)

[Richard Guenther]

On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
 wrote:
> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm  wrote:
>> I wrote a script and ported my proposed API for GCC plugins from my
>> CamelCase naming convention to an underscore_based_convention (and
>> manually fixed up things in a few places also).
>>
>> The result compiles and passes the full test suite for the Python
>> plugin; that said, I'm still breaking the encapsulation in quite a few
>> places (hey, this is an experimental prototype).
>>
>> You can see the latest version of it within the "proposed-plugin-api"
>> branch of the Python plugin here:
>> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api
>>
>> within the "proposed-plugin-api" subdirectory.
>
> Hmm, how do I get it?  I did
>
> git clone http://git.fedorahosted.org/git/proposed-plugin-api
>
> but there is nothing in gcc-python-plugin/.  And
>
> git checkout proposed-plugin-api
>
> says I'm already there ...?

Meanwhile the directory magically appeared (heh ...).

Overall it looks good - but it seems to leak GCC headers into the
plugin API (via gcc-plugin.h and input.h inclusion).  Thus, it
lacks separating the plugin API headers from the plugin API implementation
headers?  Or maybe I'm not looking at the right place.
I also dislike the use of GCC_PUBLIC_API, etc. - everything in
the plugin API headers should be obviously public - and the implementation
detail should be an implementation detail that should not need to care.

>> If this landed e.g. in GCC 4.8, would this be usable by other plugins?

For sure.  I'd say get the copyright stuff sorted out and start pushing things
into the main GCC repository - where the obvious starting point is to
get the makefile, configure and install parts correct.

I'd concentrate on providing enough API for introspection, like simple
things, counting basic-blocks, counting calls, etc.  I'm not sure we
want to expose gcc_gimple_walk_tree or gcc_gimple_print (or
the gcc_printers for a start) - the latter would something that the
python plugin
would provide, resorting to introspecting the stmt itself.

I also wonder about gcc_gimple_phi_upcast - why would you specialize
PHI nodes but not any others?  I'd have exposed gcc_gimple_code.
In general the plugin API should provide exactly one (and the most flexible)
way to do a thing (thus, not have gcc_gimple_assign_single_p) and
the high-level consumers like the python plugin should provide
nice-to-use interfaces.

Thanks,
Richard.

>> Hope this is helpful
>> Dave
>>

Re: GRAPHITE-OpenCL?

[Ludovic Courtès]

Hi,

Alexander Monakov  skribis:

> The code has been merged into graphite branch; it can be obtained via:
>
> svn co svn://gcc.gnu.org/svn/gcc/branches/graphite

Excellent, thanks!

Ludo’.

Re: unwind and type support in GCC47

[Ian Lance Taylor]

"Paulo J. Matos"  writes:

> On 30/03/12 05:11, Ian Lance Taylor wrote:
>
>> There really shouldn't be anything in the exception support that uses
>> SImode.  That would be a bug.  And I don't see anything that uses
>> SImode.  What are you looking at?  What I see is things that use mode
>> __unwind_word__, __word__, and __pointer__.  Those types are under the
>> control of your backend.
>>
>
> I was mentioning these references to SI:
> unwind-pe.h:
> static const unsigned char *
> read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
>   const unsigned char *p, _Unwind_Ptr *val)
> {
>   union unaligned
> {
>   void *ptr;
>   unsigned u2 __attribute__ ((mode (HI)));
>   unsigned u4 __attribute__ ((mode (SI)));
>   unsigned u8 __attribute__ ((mode (DI)));
>   signed s2 __attribute__ ((mode (HI)));
>   signed s4 __attribute__ ((mode (SI)));
>   signed s8 __attribute__ ((mode (DI)));
> } __attribute__((__packed__));
> ...

Hmmm, you're right, I didn't notice those.  You said that on your system
QImode is 16 bits.  These modes are being used to efficiently load
16-bit, 32-bit, and 64-bit values, in order to handle DW_EH_PE_udata2
and friends.  This code is not portable in that it assumes 8 bit bytes
and 8 bit QImode.  But I don't know how to fix it.  What is the right
way to load a 16-bit or 32-bit value on your system?


> There are also some references to mode SI in unwind-dw2.c.
>
> And there's also this:
> unwind-dw2-fde.h:typedef  int  sword __attribute__ ((mode (SI)));
>
> Why hardcode these type sizes here?   

That just looks like a bug.  It should probably use __INT32_TYPE__
instead.

Ian

Re: unwind and type support in GCC47

[Paulo J. Matos]

On 03/04/12 15:04, Ian Lance Taylor wrote:
> "Paulo J. Matos"  writes:
>
>
> Hmmm, you're right, I didn't notice those.  You said that on your system
> QImode is 16 bits.  These modes are being used to efficiently load
> 16-bit, 32-bit, and 64-bit values, in order to handle DW_EH_PE_udata2
> and friends.  This code is not portable in that it assumes 8 bit bytes
> and 8 bit QImode.  But I don't know how to fix it.  What is the right
> way to load a 16-bit or 32-bit value on your system?
>

Registers are 16bits. Minimum addressable unit is 16bits. QImode is 
16bits, HImode is 32bits, SImode is 64bits.


Loading 16bits in my system is extremely efficient since it's just the 
load of a word.

ld AL, H'beef

will do it.
My guess it that changing that structure so that I use QI instead of HI, 
HI instead of SI and SI instead of DI will work.


>
>> There are also some references to mode SI in unwind-dw2.c.
>>
>> And there's also this:
>> unwind-dw2-fde.h:typedef  int  sword __attribute__ ((mode 
(SI)));

>>
>> Why hardcode these type sizes here?
>
> That just looks like a bug.  It should probably use __INT32_TYPE__
> instead.
>

That would be great because it would make it a lot more portable across 
really weird backends, like mine. :)


--
PMatos

Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)

[David Malcolm]

On Tue, 2012-04-03 at 12:03 +0200, Richard Guenther wrote:
> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm  wrote:
> > I wrote a script and ported my proposed API for GCC plugins from my
> > CamelCase naming convention to an underscore_based_convention (and
> > manually fixed up things in a few places also).
> >
> > The result compiles and passes the full test suite for the Python
> > plugin; that said, I'm still breaking the encapsulation in quite a few
> > places (hey, this is an experimental prototype).
> >
> > You can see the latest version of it within the "proposed-plugin-api"
> > branch of the Python plugin here:
> > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api
> >
> > within the "proposed-plugin-api" subdirectory.
> 
> Hmm, how do I get it?  I did
> 
> git clone http://git.fedorahosted.org/git/proposed-plugin-api
> 
> but there is nothing in gcc-python-plugin/.  And
> 
> git checkout proposed-plugin-api
> 
> says I'm already there ...?
I'm sorry that this was unclear.

To checkout the source, on the "proposed-plugin-api" branch:

  $ git clone git://git.fedorahosted.org/gcc-python-plugin.git -b 
proposed-plugin-api
  Cloning into gcc-python-plugin...
  remote: Counting objects: 8375, done.
[...snip...]
  Resolving deltas: 100% (5774/5774), done.

Go into the new working copy:
  $ cd gcc-python-plugin/

Verify that you're on the experimental branch:
  $ git branch
  * proposed-plugin-api

The code in the root directory is specific to my Python plugin.  The
proposed generic plugin API is in a subdirectory which confusingly has
the same name as the branch (sorry):
  $ cd proposed-plugin-api

(If you're interested in the python plugin, detailed instructions on
building from source can be seen at [1])

Sorry about the confusion
Dave

[1]
http://gcc-python-plugin.readthedocs.org/en/latest/basics.html#building-the-plugin-from-source

Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)

[David Malcolm]

On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
>  wrote:
> > On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm  wrote:
> >> I wrote a script and ported my proposed API for GCC plugins from my
> >> CamelCase naming convention to an underscore_based_convention (and
> >> manually fixed up things in a few places also).
> >>
> >> The result compiles and passes the full test suite for the Python
> >> plugin; that said, I'm still breaking the encapsulation in quite a few
> >> places (hey, this is an experimental prototype).
> >>
> >> You can see the latest version of it within the "proposed-plugin-api"
> >> branch of the Python plugin here:
> >> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api
> >>
> >> within the "proposed-plugin-api" subdirectory.
> >
> > Hmm, how do I get it?  I did
> >
> > git clone http://git.fedorahosted.org/git/proposed-plugin-api
> >
> > but there is nothing in gcc-python-plugin/.  And
> >
> > git checkout proposed-plugin-api
> >
> > says I'm already there ...?
> 
> Meanwhile the directory magically appeared (heh ...).

[The ways of git are something of a mystery to me: 95% of the time it's
the best revision control system I've ever used, but 5% of the time the
most obtuse]

> Overall it looks good
Thanks for taking a look.

>  - but it seems to leak GCC headers into the
> plugin API (via gcc-plugin.h and input.h inclusion).  Thus, it
> lacks separating the plugin API headers from the plugin API implementation
> headers?  
That's true.  The big information "leak" happens inside
gcc-semiprivate-types.h, which defines the various structs that act like
pointers, each with a decl like this:

struct gcc_something {
   some_private_gcc_pointer_type inner;
};

It would be possible to make this more opaque like this:

struct gcc_something {
   struct some_private_gcc_struct *inner;
};

given that you then don't need a full definition of that inner struct
visible to users.  Though location_t is leaked, and in this approach,
there isn't a way around that, I think.


> Or maybe I'm not looking at the right place.
> I also dislike the use of GCC_PUBLIC_API, etc. - everything in
> the plugin API headers should be obviously public - and the implementation
> detail should be an implementation detail that should not need to care.

I added that macro based on the example of other plugin/embedding
systems I've seen (e.g. Python), where it's handy to make that macro be
non-trivial on some platforms.  See e.g. CPython's pyport.h:
 http://hg.python.org/cpython/file/9599f091faa6/Include/pyport.h
where the macros PyAPI_FUNC and PyAPI_DATA have a 44-line definition,
handling various different compatibility cases.

For example, GCC_PRIVATE_API could have some magic linker flag that lets
us automatically strip out those symbols so that they're not visible
externally after the compiler has been linked.

> >> If this landed e.g. in GCC 4.8, would this be usable by other plugins?
> 
> For sure.  I'd say get the copyright stuff sorted out and start pushing things
> into the main GCC repository - where the obvious starting point is to
> get the makefile, configure and install parts correct.
> 
> I'd concentrate on providing enough API for introspection, like simple
> things, counting basic-blocks, counting calls, etc.  I'm not sure we
> want to expose gcc_gimple_walk_tree or gcc_gimple_print (or
> the gcc_printers for a start) - the latter would something that the
> python plugin
> would provide, resorting to introspecting the stmt itself.
FWIW the Python plugin already heavily uses gcc's pretty-printer code,
so that *is* something I'd want to wrap (but it's fairly easy to do so).

> I also wonder about gcc_gimple_phi_upcast - why would you specialize
> PHI nodes but not any others?  I'd have exposed gcc_gimple_code.
> In general the plugin API should provide exactly one (and the most flexible)
> way to do a thing (thus, not have gcc_gimple_assign_single_p) and
> the high-level consumers like the python plugin should provide
> nice-to-use interfaces.

This touches on the biggest thing that's missing in the API: the
multitude of tree types, gimple statement types, and rtl types.  All I
added were the "base classes", and gimple-phi is the only instance so
far in the API of a subclass.

I would like the API to expose these (my plugin uses them to good
effect), but doing it in C is likely to be messy: lots of upcasting and
downcasting functions.

An alternative approach might be to bite the bullet and go to C++; maybe
something like this (caveat: I last did any C++ about a decade ago, no
idea if the following compiles):

// Everything exposed in the public headers are pure virtual functions
// leading to abstract classes: no public data
namespace gcc {

   // Abstract base class for objects managed by GCC's garbage-collector
   class gcmanaged {
   public:
  virtual void mark_in_use() const = 0;
   };

   cla

Bug in reload when forming inheritable reload information?

[Bin.Cheng]

Hi,
Recently I found a test program got wrongly reloaded, as reported in PR52804.
As the comment, I think reload_reg_reaches_end_p in reload1.c should
handle case:
The first reload type is RELOAD_FOR_INPADDR_ADDRESS;
the second reload type is RELOAD_FOR_INPADDR_ADDRESS and the reload
register is same as the first one.

In this case, the first reload is corrupted by the second one, but for now
reload_reg_reaches_end_p still returns 1, resulting in forming wrong
inheritable information,
then mis-leading following instructions.

I am working/testing a patch for this right now, also I'd like to get
some confirmation on this issue,
because RELOAD is a well-known complicated pass.

Any comments? Thanks very much.

-- 
Best Regards.

Switching to C++ by default in 4.8

[Diego Novillo]

We would like to start the process to make GCC 4.8 build in C++ mode by 
default.


The mechanics of the change are simple enough.  I volunteer to test 
changing the default on all primary targets (assuming I can get them 
from the GCC build farm).


Concurrently with this, Lawrence and Ian are working on the C++ coding 
guidelines.  The draft is stored at 
http://gcc.gnu.org/wiki/CppConventions.  They will be sending an update 
in the next few days.  The idea is to hash out the details on the wiki 
and then produce a patch to http://gcc.gnu.org/codingconventions.html.


While these two changes are independent, it probably makes sense to 
first have agreement on an initial set of coding conventions before we 
switch the default.


I expect that coding conventions will evolve quite a bit in the next few 
months, so we should do the switch after the first patch to 
codingconventions.html is approved and installed.  A reasonable initial 
version of this should cover the core language features that allow 
implementing basic conversions (for instance, those that would allow 
re-implementing vec.h).


I would like to avoid discussions to drag on indefinitely.  But, given 
the magnitude of these changes, I suppose that it may take a few days to 
hash it out.  Therefore, I propose that:


- For the coding conventions, we have the explicit approval of at least 
4 global reviewers.

- For the build changes, approval from a build maintainer should be enough.


Thanks.  Diego.

RE: [GCC Steering Committee] Android sub-port reviewer

[Fu, Chao-Ying]

Andrew Pinski wrote:

> On Mon, Apr 2, 2012 at 1:55 PM, Fu, Chao-Ying  wrote:
> >  It basically sets the MIPS target to little-endian MIPS32 
> for mips-linux-android.
> 
> That seems broken because mips-*-* is big-endian and mipsel-*-* is
> little-endian.  Is any way of fixing that before even trying to
> submitting the patch?  Because it will be the only port for mips which
> is the opposite endian which makes it out of place.

  We fixed the MIPS target to little endian, because there is only one
MIPS ABI in official NDK for Android: little-endian MIPS32 release 1.
NDK scripts are tested with mips-linux-android.  (We didn't test 
mipsel-linux-android targets.)
Note that Android software components (ex: google v8, webkit jsc) may be coded 
for
little-endian targets only.

  If GCC doesn't set the MIPS Android targets to little endian, it will be easy 
to
add a small patch into googlesource in the future.  Ex: Add -EL options for 
compilation/linking.
Thanks!

Regards,
Chao-ying

  

Re: compiling gcc 2.95.3 under ubuntu 10.04.2, x86_64

[Roman Suvorov]

Hi Richard,
Could you please provide some more instructions on how you got your 2.95 build 
using GCC 3?

I just tried using GCC 3.4.6 (from 
http://packages.ubuntu.com/hardy/amd64/gcc-3.4-base/download) and build from 
source using this command:
CC=../gcc-3.4/bin/gcc-3.4 CFLAGS=-D_FORTIFY_SOURCE=0 ./configure 
--prefix=~/gcc-2.95.3 --enable-languages=c,c++ --enable-threads=posix 
--enable-shared --host i386-pc-linux-gnu
It dies right away because it can't find cc1. I got the cc1 executable from the 
corresponding cpp 3.4.6 package 
(http://packages.ubuntu.com/hardy/amd64/cpp-3.4/download) and placed it in the 
same bin directory as the gcc-3.4 executable, but still nothing.
As you can probably guess I've never build GCC from source before.. but I can 
right away spot that the target host is i386 - I'm assuming that's due to the 
fact that GCC 2.95 doesn't even support x86_64?

Regards,
Roman.

On 03-Apr-2012, at 6:30 , Richard Guenther wrote:

> On Tue, Apr 3, 2012 at 12:21 PM, Andrew Haley  wrote:
>> On 04/02/2012 06:29 PM, Roman Suvorov wrote:
>>> Hello everyone,
>>> Not sure if this is the right place to ask this question, feel free to 
>>> point me in the right direction.
>> 
>> Redirect to gcc-help.
>> 
>>> I'm looking into the evolution of Linux kernel and this requires me
>>> to build some ancient releases (as old as 2.4.0) from source using
>>> GCC. I have gcc 4.4.3-4ubuntu5 installed on my lab machine but it's
>>> incompatible with these old sources, and the "lowest common
>>> denominator" would be gcc 2.95.3, so I've been trying to compile it
>>> from source - so far with little success.
>> 
>>> It's hard but not impossible - done before by this guy:
>>> http://www.trevorpounds.com/blog/?p=111&cpage=1#comment-102. I
>>> followed all of his suggestions but so far hasn't had much luck -
>>> most recent attempt dies with the following message:
>> 
>>> /usr/bin/ld.bfd.real: error in pic/cstrmain.o(.eh_frame); no .eh_frame_hdr 
>>> table will be created.
>>> 
>>> The URL above contains a link to my stdout/stderr logs too. Has anyone here 
>>> tried compiling such an old version of GCC? Any advice/help would be 
>>> greatly appreciated.
>> 
>> It's going to be hard.  gcc 2.95 doesn't support using x86_64 as a host,
>> so you're going to have to build in in a 32-bit virtual machine or by
>> using mock.
>> 
>> You'll have other problems too.  gcc back then wasn't so standards-
>> clean as it is now; we have a lot of warnings and better diagnostics
>> that have allowed us to clean up gcc.  I don't know why you got that
>> particular message, and as I said I can't look at your logs.  I might
>> have a try myself to build gcc 2.95 later today.
> 
> You can have success with only minor patching when you stage a 3.x
> release inbetween and use that to compile 2.95.  At least that is how
> I created my 2.95 build ;)
> 
> Richard.
> 
>> Andrew.

Re: [GCC Steering Committee] Android sub-port reviewer

[Andrew Pinski]

On Tue, Apr 3, 2012 at 10:45 AM, Fu, Chao-Ying  wrote:
> Andrew Pinski wrote:
>
>> On Mon, Apr 2, 2012 at 1:55 PM, Fu, Chao-Ying  wrote:
>> >  It basically sets the MIPS target to little-endian MIPS32
>> for mips-linux-android.
>>
>> That seems broken because mips-*-* is big-endian and mipsel-*-* is
>> little-endian.  Is any way of fixing that before even trying to
>> submitting the patch?  Because it will be the only port for mips which
>> is the opposite endian which makes it out of place.
>
>  We fixed the MIPS target to little endian, because there is only one
> MIPS ABI in official NDK for Android: little-endian MIPS32 release 1.
> NDK scripts are tested with mips-linux-android.  (We didn't test 
> mipsel-linux-android targets.)
> Note that Android software components (ex: google v8, webkit jsc) may be 
> coded for
> little-endian targets only.
>
>  If GCC doesn't set the MIPS Android targets to little endian, it will be 
> easy to
> add a small patch into googlesource in the future.  Ex: Add -EL options for 
> compilation/linking.
> Thanks!

The point is mips*-*-* is big endian and mipsel*-*-* is little endian.
 And doing adding a target which says mips-linux-android which is
little-endian is just backwards.  Is there anyway to fix the target
triplet to be mipsel-linux-android including inside the official NDK?
If not then we have a broken triplet for android.

Also it seems broken they are coded for little-endian only but that is
a different point all together.  Also there are a few MIPS64
processors out there which default normally to big-endian (octeon).


Thanks,
Andrew Pinski

Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)

[Romain Geissler]

Le 3 avr. 2012 à 18:02, David Malcolm a écrit :

> On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote:
>> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther
>>  wrote:
>>> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm  wrote:
 I wrote a script and ported my proposed API for GCC plugins from my
 CamelCase naming convention to an underscore_based_convention (and
 manually fixed up things in a few places also).
 
 The result compiles and passes the full test suite for the Python
 plugin; that said, I'm still breaking the encapsulation in quite a few
 places (hey, this is an experimental prototype).
 
 You can see the latest version of it within the "proposed-plugin-api"
 branch of the Python plugin here:
 http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api
 
 within the "proposed-plugin-api" subdirectory.
>>> 
>>> Hmm, how do I get it?  I did
>>> 
>>> git clone http://git.fedorahosted.org/git/proposed-plugin-api
>>> 
>>> but there is nothing in gcc-python-plugin/.  And
>>> 
>>> git checkout proposed-plugin-api
>>> 
>>> says I'm already there ...?
>> 
>> Meanwhile the directory magically appeared (heh ...).
> 
> [The ways of git are something of a mystery to me: 95% of the time it's
> the best revision control system I've ever used, but 5% of the time the
> most obtuse]
> 
>> Overall it looks good
> Thanks for taking a look.
> 
>> - but it seems to leak GCC headers into the
>> plugin API (via gcc-plugin.h and input.h inclusion).  Thus, it
>> lacks separating the plugin API headers from the plugin API implementation
>> headers?  
> That's true.  The big information "leak" happens inside
> gcc-semiprivate-types.h, which defines the various structs that act like
> pointers, each with a decl like this:
> 
> struct gcc_something {
>   some_private_gcc_pointer_type inner;
> };
> 
> It would be possible to make this more opaque like this:
> 
> struct gcc_something {
>   struct some_private_gcc_struct *inner;
> };
> 
> given that you then don't need a full definition of that inner struct
> visible to users.  Though location_t is leaked, and in this approach,
> there isn't a way around that, I think.

Well i think we you should define a public type like this :

typedef struct some_private_gcc_struct *gcc_something;

extern some_type retrieve_some_value(gcc_something);

Also, nothing should be noted public or private : all definitions
that will appear in a header installed in
$(gcc -print-file-name=plugin)/include will be public by definition.

Any additional header that would be needed to implement the
API should be kept separate (like the actual *.c implementing it)
and placed in the gcc/ directory in the trunk (or better something
like gcc/plugin-impl/ to start being modular). Any definition defined
in those additional headers are private.

Thus, you should define two sets of headers files (public and private ones),
plus body c files, and import only public header files from public header files.

Do you have any plan on starting integrating it to the trunk (or at least on an
new branch on the official gcc repository) soon, like suggested by Richard ?
I might help setting up the configure/makefile and later writing some wrappers.
(although i don't have write permission).

Cheers

Romain Geissler

RE: [GCC Steering Committee] Android sub-port reviewer

[Fu, Chao-Ying]

Andrew Pinski wrote:
> The point is mips*-*-* is big endian and mipsel*-*-* is little endian.
>  And doing adding a target which says mips-linux-android which is
> little-endian is just backwards.  Is there anyway to fix the target
> triplet to be mipsel-linux-android including inside the official NDK?
> If not then we have a broken triplet for android.

  I agree with what you said.

  The simplest fix is that mips-linux-android still generates big-endian code
as the MIPS target triplet design.  Don't ever set it to generate little-endian 
code automatically.
For MIPS GCC Android patches to merge to FSF GCC trunk, we will never change 
endiannes.

  Note that we did use a regular mips-linux-gnu GCC to compile Android systems 
by using -EL.
The target of "mips-linux-android" is just invented to work with NDK scripts.
And people can freely create "mipsel-linux-*" toolchains to compile Android 
systems directly,
or create "mips-linux-*" toolchains to compile Android systems with -EL.

  The MIPS NDK script patch was just merged to googlesource last night.
I can work on another patch to use -EL options, but to let
"mips-linux-andoird" generate big-endian code.  Is this solution ok for you?

  Thanks!

Regards,
Chao-ying

Re: [GCC Steering Committee] Android sub-port reviewer

[Maxim Kuvyrkov]

On 4/04/2012, at 6:28 AM, Fu, Chao-Ying wrote:

> Andrew Pinski wrote:
>> The point is mips*-*-* is big endian and mipsel*-*-* is little endian.
>> And doing adding a target which says mips-linux-android which is
>> little-endian is just backwards.  Is there anyway to fix the target
>> triplet to be mipsel-linux-android including inside the official NDK?
>> If not then we have a broken triplet for android.
> 
>  I agree with what you said.
> 
>  The simplest fix is that mips-linux-android still generates big-endian code
> as the MIPS target triplet design.  Don't ever set it to generate 
> little-endian code automatically.
> For MIPS GCC Android patches to merge to FSF GCC trunk, we will never change 
> endiannes.
> 
>  Note that we did use a regular mips-linux-gnu GCC to compile Android systems 
> by using -EL.
> The target of "mips-linux-android" is just invented to work with NDK scripts.
> And people can freely create "mipsel-linux-*" toolchains to compile Android 
> systems directly,
> or create "mips-linux-*" toolchains to compile Android systems with -EL.
> 
>  The MIPS NDK script patch was just merged to googlesource last night.
> I can work on another patch to use -EL options, but to let
> "mips-linux-andoird" generate big-endian code.  Is this solution ok for you?

I encourage you to submit the MIPS Android patches to gcc-patches@.  And, as 
long as your changes preserve the status quo of mips-*-* being big-endian by 
default and mipsel-*-* being little-endian by default, there should be no major 
obstacles to merge those in.

Thank you,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

Re: Switching to C++ by default in 4.8

[Paweł Sikora]

On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> 
> Concurrently with this, Lawrence and Ian are working on the C++ coding 
> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.

what about using http://astyle.sourceforge.net/astyle.html for code checkers?
what about -Woverloaded-virtual [-Werror] by default?

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

OK, you've all made clear you have your sensible reasons to have the '.info'
files generated in the builddir in your use cases.  Since the actual change
required by automake to allow this is very small and safe, I'm ready to do
it (see attached patch, which I will push in a couple of days to 'master' if
there is no objection).

But since I'm not yet ready to publish this new feature, I intend to make
it available only though the new, undocumented option named (literally)
"hack!info-in-builddir".  I hope this is acceptable to you.

Regards,
  Stefano
>From de715b44d25ad523b558d7321ce87bcf8c0cdb09 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Stefano Lattarini 
Date: Tue, 3 Apr 2012 22:02:55 +0200
Subject: [PATCH] texinfo: hack to allow '.info' files to be generated in the
 builddir

The possibility to force the '.info' files to be generated in the
builddir rather than the srcdir is requested by the developers of
GCC, GDB, GNU binutils and the GNU bfd library.  The lack of such
a possibility being the last obstacle to the removal of the support
for Cygnus-style trees (for which such a setup for '.info' files
generation was automatically implied).

So allow the developers to have the '.info' files to be generated
in the builddir rather than the srcdir, through the use of the new
*undocumented* option '!hack!info-in-builddir' (whose name should
made it clear that it is not meant for public consumption).

See also the extensive discussion about automake bug#11034.

* lib/Automake/Options.pm (_is_valid_easy_option): Recognize the
new option.
* automake.in (handle_texinfo_helper): If it's set, initialize
'$insrc' to '0', so that info files will be generated in the
builddir.  Adjust comments to match.
* tests/txinfo-builddir.test: New test.
* tests/list-of-tests.mk: Add it.

Signed-off-by: Stefano Lattarini 
---
 automake.in|   28 +++-
 lib/Automake/Options.pm|1 +
 tests/list-of-tests.mk |1 +
 tests/txinfo-builddir.test |   74 
 4 files changed, 95 insertions(+), 9 deletions(-)
 create mode 100755 tests/txinfo-builddir.test

diff --git a/automake.in b/automake.in
index f96e36b..b793a12 100644
--- a/automake.in
+++ b/automake.in
@@ -3278,15 +3278,25 @@ sub handle_texinfo_helper ($)
   # have a single variable ($INSRC) that controls whether
   # the current .info file must be built in the source tree
   # or in the build tree.  Actually this variable is switched
-  # off for .info files that appear to be cleaned; this is
-  # for backward compatibility with package such as Texinfo,
-  # which do things like
-  #   info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
-  #   DISTCLEANFILES = texinfo texinfo-* info*.info*
-  #   # Do not create info files for distribution.
-  #   dist-info:
-  # in order not to distribute .info files.
-  my $insrc = ($out_file =~ $user_cleaned_files) ? 0 : 1;
+  # off in two cases:
+  #  (1) For '.info' files that appear to be cleaned; this is for
+  #  backward compatibility with package such as Texinfo,
+  #  which do things like
+  #info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
+  #DISTCLEANFILES = texinfo texinfo-* info*.info*
+  ## Do not create info files for distribution.
+  #dist-info:
+  #  in order not to distribute .info files.
+  #  (2) When the undocumented option '!hack!info-in-builddir'
+  #  is given.  This is done to allow the developers of
+  #  GCC, GDB, GNU binutils and the GNU bfd library to force
+  #  force the '.info' files to be generated in the builddir
+  #  rather than the srcdir, as was once done when the (now
+  #  obsolete) 'cygnus' option was given.  See automake
+  #  bug#11034 for more discussion.
+  my $insrc = 1;
+  $insrc = 0 if $out_file =~ $user_cleaned_files;
+  $insrc = 0 if option '!hack!info-in-builddir';
 
   my $soutdir = '$(srcdir)/' . $outdir;
   $outdir = $soutdir if $insrc;
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 2f977bd..ee33837 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -267,6 +267,7 @@ sub _is_valid_easy_option ($)
 {
   my $opt = shift;
   return scalar grep { $opt eq $_ } qw(
+!hack!info-in-builddir
 check-news
 color-tests
 cygnus
diff --git a/tests/list-of-tests.mk b/tests/list-of-tests.mk
index de022a2..fa57ce5 100644
--- a/tests/list-of-tests.mk
+++ b/tests/list-of-tests.mk
@@ -1181,6 +1181,7 @@ txinfo31.test \
 txinfo32.test \
 txinfo33.test \
 txinfo-unrecognized-extension.test \
+txinfo-builddir.test \
 transform.test \
 transform2.test \
 transform3.test \
diff --git a/tests/txinfo-builddir.test b/tests/txinfo-builddir.test
new file mode 100755
index 000..64ca190
--- /dev/null
+++ b/tests/txinfo-builddir.test
@@ -0,0 +1,74 @@
+#! /bin/sh
+# Copyright (C) 2012 Fre

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/03/2012 10:04 PM, Stefano Lattarini wrote:
> OK, you've all made clear you have your sensible reasons to have the '.info'
> files generated in the builddir in your use cases.  Since the actual change
> required by automake to allow this is very small and safe, I'm ready to do
> it (see attached patch, which I will push in a couple of days to 'master' if
> there is no objection).
> 
> But since I'm not yet ready to publish this new feature, I intend to make
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir".  I hope this is acceptable to you.
> 
Oops, with this squashed in:

  diff --git a/tests/txinfo-builddir.test b/tests/txinfo-builddir.test
  index 64ca190..a09af80 100755
  --- a/tests/txinfo-builddir.test
  +++ b/tests/txinfo-builddir.test
  @@ -27,7 +27,7 @@ required=makeinfo
   echo AC_OUTPUT >> configure.ac

   cat > Makefile.am << 'END'
  -AUTOMAKE_OPTIONS = cygnus ##!hack!info-in-builddir
  +AUTOMAKE_OPTIONS = !hack!info-in-builddir
   info_TEXINFOS = foo.texi subdir/bar.texi
   subdir_bar_TEXINFOS = subdir/inc.texi
   END

Sorry for the noise,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/03/2012 10:05 PM, Stefano Lattarini wrote:
> On 04/03/2012 10:04 PM, Stefano Lattarini wrote:
>> OK, you've all made clear you have your sensible reasons to have the '.info'
>> files generated in the builddir in your use cases.  Since the actual change
>> required by automake to allow this is very small and safe, I'm ready to do
>> it (see attached patch, which I will push in a couple of days to 'master' if
>> there is no objection).
>>
>> But since I'm not yet ready to publish this new feature, I intend to make
>> it available only though the new, undocumented option named (literally)
>> "hack!info-in-builddir".  I hope this is acceptable to you.
>>
On a second though, by double-checking the existing code, I couldn't see how
the 'cygnus' option could possibly influence the location of the generated
info files -- and it turned out it didn't!  Despite what was documented in
the manual, the 'cygnus' option did *not* cause the generated '.info' files
to be placed in the builddir (see attached test case).  This is true for at
least for automake 1.9.6, 1.10.3, 1.11.1, 1.11.4, and automake built from
the master branch (I've checked them all).  Since nobody ever complained
about such a breakage, I conclude that the feature was not truly needed, and
I'm thus withdrawing my previous patch.

Regards,
  Stefano
#! /bin/sh
# Copyright (C) 2012 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .

# The cygnus option do not really cause the '.info' files to be
# generated in the builddir!

required=makeinfo
. ./defs || Exit 1

cat >> configure.ac < Makefile.am << 'END'
AUTOMAKE_OPTIONS = cygnus -Wno-override
info_TEXINFOS = foo.texi
END

cat > foo.texi << 'END'
\input texinfo
@setfilename foo.info
@settitle foo
@node Top
Hello walls.
@bye
END

$ACLOCAL
$AUTOMAKE --add-missing
$AUTOCONF

mkdir build
cd build
../configure
$MAKE info
ls -l . ..
test -f foo.info
test ! -f ../foo.info

:

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

> "Stefano" == Stefano Lattarini  writes:

Stefano> On a second though, by double-checking the existing code, I
Stefano> couldn't see how the 'cygnus' option could possibly influence
Stefano> the location of the generated info files -- and it turned out
Stefano> it didn't!  Despite what was documented in the manual, the
Stefano> 'cygnus' option did *not* cause the generated '.info' files to
Stefano> be placed in the builddir (see attached test case).

It certainly does for me:

barimba. pwd
/home/tromey/gnu/baseline-gdb/build/binutils
barimba. grep '^srcdir = ' Makefile
srcdir = ../../src/binutils
barimba. find . -name 'binutils.info'
./doc/binutils.info
barimba. find ../../src/binutils -name 'binutils.info'
barimba.

How did you test it?
If you built from a distribution tar, then it is expected that the info
file would be in srcdir.

Tom

Re: Switching to C++ by default in 4.8

[Ian Lance Taylor]

Paweł Sikora  writes:

> On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
>> 
>> Concurrently with this, Lawrence and Ian are working on the C++ coding 
>> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
>
> what about using http://astyle.sourceforge.net/astyle.html for code checkers?

I don't think we want to automatically reformat the entire GCC codebase.
Or at least, if we do, we don't want to confuse that with the C++
transition.


> what about -Woverloaded-virtual [-Werror] by default?

Sounds good to me.  -Werror will of course be on by default for stage 2
and 3 development builds.  Want to add a cxx_strict_warn along the lines
of c_strict_warn in gcc/configure.ac and gcc/Makefile.in?

Ian

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Ian Lance Taylor]

Stefano Lattarini  writes:

> But since I'm not yet ready to publish this new feature, I intend to make
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir".  I hope this is acceptable to you.

Sure, works for me.

Thanks.

Ian

Re: Switching to C++ by default in 4.8

[Paweł Sikora]

On Tuesday 03 of April 2012 13:51:56 Ian Lance Taylor wrote:
> Paweł Sikora  writes:
> 
> > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> >> 
> >> Concurrently with this, Lawrence and Ian are working on the C++ coding 
> >> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
> >
> > what about using http://astyle.sourceforge.net/astyle.html for code 
> > checkers?
> 
> I don't think we want to automatically reformat the entire GCC codebase.
> Or at least, if we do, we don't want to confuse that with the C++
> transition.

i'm only suggesting that astyle (or another tool) can be used in svn pre-commit
hook to verifying gnu formatting rules (incoming files can be extracted from
svn transaction to /tmp and checked). manual formatting rules reviewing 
@gcc-patches
is waste of time.

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Pedro Alves]

On 04/03/2012 09:04 PM, Stefano Lattarini wrote:

> OK, you've all made clear you have your sensible reasons to have the '.info'

...
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir".  I hope this is acceptable to you.
...
> *undocumented* option '!hack!info-in-builddir' (whose name should
> made it clear that it is not meant for public consumption).

So will this be called a hack forever, or will the naming be revisited
before a release?  IMO, either the feature is sensible, and there doesn't
seem to be a good reason other users couldn't also use it, and hence it
should get a non-hackish name and be documented; or it isn't sensible, and
then it shouldn't exist.  Why the second-class treatment?

-- 
Pedro Alves

Scalability micro-conference topic proposals (LPC2012)

[Mathieu Desnoyers]

Hi,

We are organizing a micro-conference on scaling both upwards (many
cores) and downwards (low footprint, energy efficiency) that targets
all layers of the software stack. Our intent is to bring together
application, libraries and kernel developers to discuss the scalability
issues they currently face, and get exposure for the ongoing work on
scalability infrastructure.

Suggestions of topics are welcome. If you would like to present, please
let us know: we have lightnening-talk slots and a few 30 minutes slots
available. Presentations should be oriented towards stimulating
discussion over currently faced scalability problems and/or work in
progress in the area of scalability.

The micro-conference will be held between August 29-31, at LinuxCon
North America 2012, in San Diego.

   http://www.linuxplumbersconf.org/2012/

The Scaling Micro-Conference page is available at:

   http://wiki.linuxplumbersconf.org/2012:scaling

Best Regards,

Mathieu Desnoyers & Paul E. McKenney

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Miles Bader]

Pedro Alves  writes:
>> OK, you've all made clear you have your sensible reasons to have the '.info'
>
> ...
>> it available only though the new, undocumented option named (literally)
>> "hack!info-in-builddir".  I hope this is acceptable to you.
> ...
>> *undocumented* option '!hack!info-in-builddir' (whose name should
>> made it clear that it is not meant for public consumption).
>
> So will this be called a hack forever, or will the naming be revisited
> before a release?  IMO, either the feature is sensible, and there doesn't
> seem to be a good reason other users couldn't also use it, and hence it
> should get a non-hackish name and be documented; or it isn't sensible, and
> then it shouldn't exist.  Why the second-class treatment?

I suspect there are better, cleaner, ways to accomplish the underlying
goal, but I suppose the gcc maintainers don't want to spend the time
fiddling around with their build infrastructure for such a minor
issue...

-miles

-- 
Alone, adj. In bad company.

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo  wrote:
>
> We would like to start the process to make GCC 4.8 build in C++ mode by
> default.
>
> The mechanics of the change are simple enough.  I volunteer to test changing
> the default on all primary targets (assuming I can get them from the GCC
> build farm).

I appreciate the motivation, but this may cause major problems on
non-GNU/Linux platforms.  Testing on all primary targets is not
enough.

Do you expect GCC to be able to bootstrap starting from a vendor C++
compiler or will this require G++?

What is the earliest release of G++ that will allow GCC to bootstrap?

Thanks, David

Re: Switching to C++ by default in 4.8

[Ian Lance Taylor]

David Edelsohn  writes:

> Do you expect GCC to be able to bootstrap starting from a vendor C++
> compiler or will this require G++?

In principle it should be possible to start from a vendor C++ compiler.
Of course we will have to test in order to see.

> What is the earliest release of G++ that will allow GCC to bootstrap?

Another thing that is worth testing.  Right now I would anticipate that
even fairly old releases of G++ can bootstrap GCC.  However, we will
need to decide what old release we want to ensure works.

Ian

Re: Switching to C++ by default in 4.8

[Miles Bader]

Ian Lance Taylor  writes:
>> What is the earliest release of G++ that will allow GCC to bootstrap?
>
> Another thing that is worth testing.  Right now I would anticipate that
> even fairly old releases of G++ can bootstrap GCC.  However, we will
> need to decide what old release we want to ensure works.

4.2 at the latest might be a good idea, given its continued widespread
use in "scared of the GPL3"[*] communities (*BSD, the pre-clang llvm
frontend, the pathscale/path64 compiler frontend, etc)...

[*] stronger language omitted for diplomatic reasons

-miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: Switching to C++ by default in 4.8

[Basile Starynkevitch]

On Tue, 03 Apr 2012 13:51:56 -0700
Ian Lance Taylor  wrote:

> Paweł Sikora  writes:
> 
> > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> >> 
> >> Concurrently with this, Lawrence and Ian are working on the C++ coding 
> >> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
> >
> > what about using http://astyle.sourceforge.net/astyle.html for code 
> > checkers?
> 
> I don't think we want to automatically reformat the entire GCC codebase.
> Or at least, if we do, we don't want to confuse that with the C++
> transition.


But I believe we could install as a rule that every genuine C++ source file be 
indented
with 
   astyle -gnu -s2
and perhaps even provide an 'indent' make target for that purpose.

I really think that systematic reindentation would help us a lot.

What do you think?

Cheers
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***