Re: defining add in a new port

[Jean-Marc Saffroy]

On 01/28/2011 06:44 PM, Ian Lance Taylor wrote:
> Jean-Marc Saffroy  writes:
> 
>> error: insn does not satisfy its constraints:
>> (insn 1424 1423 141 (set (reg:DI 2 r2)
>> (plus:DI (reg:DI 2 r2)
>> (const_int 40 [0x28])))
>> /home/jmsaffroy/cygnus/src/newlib/libc/time/strptime.c:165 24 {adddi3}
>>  (expr_list:REG_EQUIV (plus:DI (reg/f:DI 70 a6)
>> (const_int 40 [0x28]))
>> (nil)))
> 
> You should find out what is creating this insn.  Is it being created by
> reload, or is it being created by some pass that runs after reload?

With gcc -da, I see that it appears in dump .195r.ira, so that's reload,
right?

> It is likely that you need to make adddi3 a define_expand which tests
> reload_in_progress and reload_completed.  If those are the case, you
> will need to explicitly convert
> (set (reg:DI DREG1) (plus:DI (reg:DI DREG2) (const_int N)))
> into
> (set (reg:DI DREG1) (const_int N))
> (set (reg:DI DREG1) (plus:DI (reg:DI DREG1) (REG:DI DREG2)))
> 

Ah, but here it happens that DREG1 and DREG2 (r2 and a6 above) are
different types of registers, and I can't add them directly. And since
at this point I won't be allowed to allocate any reg (right?), I guess I
will have to do something like:

(set DREG2 (plus DREG2 N))
(set DREG1 DREG2)
(set DREG2 (plus DREG2 -N))

And that only works if N isn't too big for adds with DREG2. I hope it
will turn out to be an uncommon case, or can be optimized away in
subsequent passes.

> For a much more sophisticated version of this, see, e.g., addsi3 in the
> ARM target.
> 
> Ian
> 

Ok, I'll look into it.

Thanks a lot!


JM

Making gcc -no-canonical-prefixes the default?

[Simon Baldwin]

A quick question about -no-canonical-prefixes...

By default, gcc calls realpath() on prefixes generated relative to
argv[0] in the gcc driver.  If gcc is held as a "symlink farm" the
realpath() makes it fail (absent a lot of messy -B, -L, -isytem and so
on).  It complains about not finding cc1 or cc1plus in libexec.

-no-canonical-prefixes turns off realpath() to make gcc work cleanly
when stored this way.

Does anyone know a reason why -no-canonical-prefixes could not become
the gcc default?  Are there gcc configurations that must have the
realpath()?  The flag is benign on normally laid out gcc
installations.

If it did become the default case, would adding a symmetrical
-canonical-prefixes to turn realpath() back on be worthwhile?

Thanks.

-- 
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902

Re: defining add in a new port

[Ian Lance Taylor]

Jean-Marc Saffroy  writes:

> On 01/28/2011 06:44 PM, Ian Lance Taylor wrote:
>> Jean-Marc Saffroy  writes:
>> 
>>> error: insn does not satisfy its constraints:
>>> (insn 1424 1423 141 (set (reg:DI 2 r2)
>>> (plus:DI (reg:DI 2 r2)
>>> (const_int 40 [0x28])))
>>> /home/jmsaffroy/cygnus/src/newlib/libc/time/strptime.c:165 24 {adddi3}
>>>  (expr_list:REG_EQUIV (plus:DI (reg/f:DI 70 a6)
>>> (const_int 40 [0x28]))
>>> (nil)))
>> 
>> You should find out what is creating this insn.  Is it being created by
>> reload, or is it being created by some pass that runs after reload?
>
> With gcc -da, I see that it appears in dump .195r.ira, so that's reload,
> right?

Right.


>> It is likely that you need to make adddi3 a define_expand which tests
>> reload_in_progress and reload_completed.  If those are the case, you
>> will need to explicitly convert
>> (set (reg:DI DREG1) (plus:DI (reg:DI DREG2) (const_int N)))
>> into
>> (set (reg:DI DREG1) (const_int N))
>> (set (reg:DI DREG1) (plus:DI (reg:DI DREG1) (REG:DI DREG2)))
>> 
>
> Ah, but here it happens that DREG1 and DREG2 (r2 and a6 above) are
> different types of registers, and I can't add them directly.

The insn you showed is adding a constant to a DREG.  There is no
addition of a DREG and an AREG, and I would not expect reload to
generate any such addition either.  Are you looking at a different insn?
Don't get confused by the REG_EQUIV note, it's irrelevant here.

Ian

Re: GCC 4.3.5 Status Report (2010-05-22)

[Gerald Pfeifer]

On Sun, 23 May 2010, Richard Guenther wrote:
>> I am wondering, should I stop the weekly snapshot for the GCC 4.3
>> branch and just create them ad hoc when there is demand?
> It would be nice if the scripts could check whether only DATESTAMP
> changes were done since the last snapshot ...

How can this best done?  This is related to the other thread with
Joseph, and I'd be happy to give it a try, just looking for ideas.

>> Are you (release managers) planning to do a 4.3.6 release still?
> I'm not sure, we'll have to discuss this (it obviously depends on the
> amount of patches going to the branch and the amount of testing
> it still receives).

Given that we are not to far away from GCC 4.6.0, I suggest we
consider stopping GCC 4.3 snapshots (but keep SVN open as long
as people care about it and I'll be happy to run a manual snapshot
upon request).

Any objections?

Gerald

Re: Making gcc -no-canonical-prefixes the default?

[Joseph S. Myers]

On Fri, 28 Jan 2011, Simon Baldwin wrote:

> A quick question about -no-canonical-prefixes...
> 
> By default, gcc calls realpath() on prefixes generated relative to
> argv[0] in the gcc driver.  If gcc is held as a "symlink farm" the
> realpath() makes it fail (absent a lot of messy -B, -L, -isytem and so
> on).  It complains about not finding cc1 or cc1plus in libexec.
> 
> -no-canonical-prefixes turns off realpath() to make gcc work cleanly
> when stored this way.
> 
> Does anyone know a reason why -no-canonical-prefixes could not become
> the gcc default?  Are there gcc configurations that must have the
> realpath()?  The flag is benign on normally laid out gcc
> installations.

I think the point of the default is that you can create a symlink in your 
PATH to a single gcc binary in a tree installed elsewhere, and that will 
work OK because the symlink is resolved before locating the rest of the 
tree.  Certainly I use such symlinks for convenient access to 
installations of different GCC versions.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Making gcc -no-canonical-prefixes the default?

[Ian Lance Taylor]

Simon Baldwin  writes:

> By default, gcc calls realpath() on prefixes generated relative to
> argv[0] in the gcc driver.  If gcc is held as a "symlink farm" the
> realpath() makes it fail (absent a lot of messy -B, -L, -isytem and so
> on).  It complains about not finding cc1 or cc1plus in libexec.
>
> -no-canonical-prefixes turns off realpath() to make gcc work cleanly
> when stored this way.
>
> Does anyone know a reason why -no-canonical-prefixes could not become
> the gcc default?  Are there gcc configurations that must have the
> realpath()?  The flag is benign on normally laid out gcc
> installations.
>
> If it did become the default case, would adding a symmetrical
> -canonical-prefixes to turn realpath() back on be worthwhile?

Some archealogy turned up this as the reason canonicalization was
inserted:

http://gcc.gnu.org/ml/gcc/2003-02/msg01121.html
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01697.html

Also relevant here is http://gcc.gnu.org/PR29931 .

So it seems like people want it both ways.  Some people want to invoke a
symlink which points to the real gcc, which requires canonicalization.
Some people want the real gcc to be a symlink which points elsewhere,
which requires non-canonicalization.  I don't know what the best choice
is.  Neither case seems particularly common to me.

The only argument I can think of is that it is easy to avoid having a
symlink which points to the real gcc.  You can use a tiny shell script
instead.  Whereas it's not that easy to change the other case, if you
had a reason to set things up that way.  So that suggests that we should
change the current default.  But I don't find this argument to be
especially convincing.

Since Gerald made the complaint which introduced the issue, I've CC'ed
him to see if he has any comments.

Ian

Re: Making gcc -no-canonical-prefixes the default?

[Dave Korn]

On 28/01/2011 23:05, Ian Lance Taylor wrote:
> So it seems like people want it both ways.  Some people want to invoke a
> symlink which points to the real gcc, which requires canonicalization.
> Some people want the real gcc to be a symlink which points elsewhere,
> which requires non-canonicalization.  I don't know what the best choice
> is.  Neither case seems particularly common to me.

  I think the case which is particularly common is the alternatives system,
which has a chain of symlinks finally pointing to a real gcc.  (That works
just fine with the current default, AFAIK, although that may be only because
the real gcc is in $PATH?)

cheers,
  DaveK

Re: Building Secondary Languages After Newlib is Installed

[Ralf Corsepius]

On 01/28/2011 07:49 AM, Ian Lance Taylor wrote:

Ralf Corsepius  writes:


On 01/27/2011 07:15 PM, Joel Sherrill wrote:


What is the preferred combination of
--enable-newlib and --with-newlib settings
to build with newlib in the gcc source tree
but not build it and use the installed copy
for the Ada and Go builds?

Theoretically, none at all, because building against an installed
newlib should be equivalent to "standard cross-building".

But Joel has newlib in his source tree, so won't it get built by
default?  That's what he wants to avoid.



I realize my answer as too brief.

What I had in mind was a 2 step bootstrap:
1)  An initial built run, aiming at building newlib:
- configure and build gcc+newlib one-tree style (--with-newlib 
--enable-language=c);

- Install the generated newlib, do not install the gcc related parts.

2) A second build run only aiming at building gcc:
- Remove the build tree.
- Remove newlib from the source tree
- reconfigure gcc without any newlib specific option and build again.

step 2) then would be an ordinary cross-compile.

Actually, unless the set of multilibs changes (and changes to gcc are 
moderate), step 1) is only necessary once and can be replaced with 
standalone building newlib.


Then this all would collapse to a traditional incremental gcc+libc 
building scheme.



 (I say this without having tested it.)

It's been a while since I tried this. It once used to work.


Ralf

Re: libgo multilib issues.

[Rainer Orth]

Ian Lance Taylor  writes:

>> I would suggest:
>>
>> GOARCH=mips# o32
>> GOARCH=mips64n32   # Would you believe n32?
>> GOARCH=mips64n64   # ...n64
>
> I think the only real question is whether that first "64" helps.

I don't think so: in the n64 case, it's just double, and for n32 it's
pretty meaningless: this would be like calling 32-bit sparc on a 64-bit
CPU sparc64-32 or something.

> Perhaps we should just use mipso32, mipsn32, and mipsn64?  Or should we

That would be my preference.

> just use mips instead of mipso32?

Please no: at least on IRIX (don't know about Linux/MIPS), GCC defaults
to N32 and O32 has been deprecated in 4.5 and removed in 4.6.  The
default ABI (which would be mips) depends on the target OS, the ABIs
don't.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Building Secondary Languages After Newlib is Installed

[Andreas Schwab]

Ralf Corsepius  writes:

> - Remove newlib from the source tree

--without-newlib should probably be enough.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

NetBSD bootstrap (was: Target deprecations for 4.6)

[Jonathan Wakely]

On 28 January 2011 01:11, Joseph S. Myers wrote:
>
> * a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*,
> i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd*
> not matching vax-*-netbsdelf*).

This implies some x86 targets are expected to work, but NetBSD-current
can't build recent versions of gcc on x86 at all, due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147

My patch is still waiting for review:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01280.html

Re: Building Secondary Languages After Newlib is Installed

[Ralf Corsepius]

On 01/28/2011 10:15 AM, Andreas Schwab wrote:

Ralf Corsepius  writes:


- Remove newlib from the source tree


--without-newlib should probably be enough.


Good point, agreed.

In case of Joel and rtems the situation probably can be furtherly 
simplified:


RTEMS has gcc-4.5.5-compiled newlib-rpms - Provided the set of multilibs 
hasn't changed (and gcc hasn't changed too much), it probably will 
suffice to install these newlib rpms and use them to build gcc against them.


Ralf

gccsense patch against vanilla gcc 4.5.2

[asmwarrior]

There is a discussion about codecompletion feature of gcc, see
http://gcc.gnu.org/ml/gcc/2010-04/msg00433.html

since the author did not update it for about nearly a year.
Now, I have create a patch to against vanilla gcc 4.5.2, I have tested 
it under Windows, and it works fine.

see:
http://forums.codeblocks.org/index.php/topic,13812.msg94824.html#msg94824

From my point of view, the codecompletion feature can not implemented 
by a gcc plugin.
It would be possible to create a gcc library to let other IDEs to use 
this kind of feature.


Any ideas?

asmwarrior
ollydbg from codeblocks' forum

Heads up: please help documenting *internal* GCC changes for 4.6

[Laurynas Biveinis]

I have just added a new section (approved by Gerald) to the bottom of
http://gcc.gnu.org/gcc-4.6/changes.html

Its intention is to mention noteworthy internal changes, i.e. changes
interesting for, say, maintainers of backends/frontends outside the
tree, and of course plugin developers upgrading from 4.5 to 4.6.

So please feel free to add entries there concerning the areas you maintain.

Thanks,
-- 
Laurynas

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

[Laurynas Biveinis]

2011/1/27 Richard Guenther :
> On Thu, Jan 27, 2011 at 1:23 PM, Laurynas Biveinis
>  wrote:
>> The --enable-checking=valgrind does two things. First, it provides
>> Valgrind annotations for internal GCC allocators so that Valgrind has
>> a better idea about memory blocks which are not supposed to be
>> accessed. Second, it actually invokes Valgrind on every compiler
>> invocation. This makes the option very nice for e.g. ensuring that
>> bootstrap and testsuite are Valgrind-clean. However if one wants to
>> use Valgrind only to analyze a particular testcase, then the price of
>> full Valgrind'ified bootstrap is prohibitive.
>>
>> Thus I propose to separate the two. To avoid introducing another
>> --enable-checking option, let's move the annotations to the "misc"
>> checking and also enable "misc" too if "valgrind" is requested. Both
>> these options are disabled for releases, so no performance loss there.
>>
>> There are two drawbacks I can think of. First, if one wants Valgrind
>> annotations but does not have the required headers, then the compiler
>> will be built without them - silently (currently
>> --enable-checking=valgrind fails if headers are not found). Second,
>> the compiler binary will be built slightly different if "misc" is
>> enabled depending on the presence or absence of those headers. I
>> believe these are minor enough.
>>
>> I have a prototype patch which I've been using on gc-improv (not
>> committed there yet).
>>
>> What do you think?
>
> I think we should drop the behavior that --enable-checking=valgrind
> invokes valgrind, this seems like an odd feature.  Doing the annotations
> under an --enable-checking flag also sounds odd, we for example
> have --enable-gather-detailed-mem-stats, I'd have expected a
> --enable-valgrind-annotations to do that.
>
> I have no preference how to change the existing (odd) behavior, but
> maybe introduce --enable-valgrind-annotations for the annotations
> and enable that when valgrind checking is enabled?

One thing which I like about having annotations under enable-checking
is that there is no need to reconfigure and rebuild in order to use
valgrind - just run it and it DTRT. I find this very convenient.

>
> Richard.
>



-- 
Laurynas

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

[Laurynas Biveinis]

2011/1/27 H.J. Lu :
> I think it is useful. I have run --enable-checking=valgrind once and it
> took daays to finish.  But I haven't got time analyze the result.

Do you mean, bootstrap + testsuite? IIRC someone submitted a few bug
reports (fixed now) in a row some three years ago which looked like
testsuite Valgrind failures.

-- 
Laurynas

Re: Heads up: please help documenting *internal* GCC changes for 4.6

[Basile Starynkevitch]

On Fri, 28 Jan 2011 14:43:28 +0200
Laurynas Biveinis  wrote:

> I have just added a new section (approved by Gerald) to the bottom of
> http://gcc.gnu.org/gcc-4.6/changes.html
> 
> Its intention is to mention noteworthy internal changes, i.e. changes
> interesting for, say, maintainers of backends/frontends outside the
> tree, and of course plugin developers upgrading from 4.5 to 4.6.
> 


I am not sure to understand what is the social rules to modify that. I
suppose that any patch to that page should be approved with the same
strong process as patches to trunk code?

I am not sure to understand the technical ways to modify that; is CVS
still mandatory?

That page says.

>>> The gengtype utility, which previously was internal to the GCC build 
>>> process, has been
>>> enchanced to provide GC root information for plugins as necessary.

Perhaps we should mention the gtype.state file also. Unfortunately,
neither gengtype nor gtype.state are installed (unless someone pushed a
patch for that which I did not pay attention to; I certainly didn't).

So perhaps a possible phrasing might eventually become

The gengtype utility, which previously was internal to the GCC build
process, has been enchanced to provide GC root information for plugins
as necessary. The entire internal state of gengtype (describing the
large set of GTY-ed types) is now persistent (in file gtype.state).
Therefore, plugins can use GTY annotations without needing the
availability of the GCC compiler source and build trees 

Comments are welcome.

Regards.
-- 
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} ***

Plans about increasing modularity by splitting tree/RTL more?

[Laurynas Biveinis]

On gc-improv I am working on PCH (mis-)feature that it stores a few
RTXes in a PCH file through tree (think tree_decl_with_rtl). I would
like to keep GTY completely away from RTL and that requires keeping
away RTL from PCH too.

In recent discussions on increasing GCC modularity, were there any
suggestions or plans e.g. get rid of tree_decl_with_rtl or similar? If
there were, I could direct my work along those lines.

Thanks,
-- 
Laurynas

Re: Heads up: please help documenting *internal* GCC changes for 4.6

[Laurynas Biveinis]

2011/1/28 Basile Starynkevitch :
>> Its intention is to mention noteworthy internal changes, i.e. changes
>> interesting for, say, maintainers of backends/frontends outside the
>> tree, and of course plugin developers upgrading from 4.5 to 4.6.
>>
>
>
> I am not sure to understand what is the social rules to modify that. I
> suppose that any patch to that page should be approved with the same
> strong process as patches to trunk code?

It needs to be reviewed, but it's much easier IMHO.

> I am not sure to understand the technical ways to modify that; is CVS
> still mandatory?

Yes.

> Perhaps we should mention the gtype.state file also.

I think that mentioning gtype.state--very shortly--is a good idea.
Would you like to prepare the patch with your suggested wording?

-- 
Laurynas

Re: Proposal: Improving patch tracking and review using Rietveld

[Diego Novillo]

On Thu, Jan 27, 2011 at 19:44, Joseph S. Myers  wrote:
> On Wed, 26 Jan 2011, Diego Novillo wrote:
>
>> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided
>> the submitter added gcc-patches to the CC list).
>
>  appears to be a
> patch sent using this system where it failed to include the patch in the
> message to gcc-patches.

Hm, yes.  I hadn't noticed it because I'm not actually used to the
patch being included (we conduct reviews on the web interface
directly).  The issue is with the length of the original patch.  If
it's too long, it will not include it in the initial message.

I am updating the wiki documentation to address this problem.  The
patch will have to be sent in a separate message, if we want it to
show up on the list.


Diego.

Re: NetBSD bootstrap (was: Target deprecations for 4.6)

[Joseph S. Myers]

On Fri, 28 Jan 2011, Jonathan Wakely wrote:

> On 28 January 2011 01:11, Joseph S. Myers wrote:
> >
> > * a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*,
> > i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd*
> > not matching vax-*-netbsdelf*).
> 
> This implies some x86 targets are expected to work, but NetBSD-current
> can't build recent versions of gcc on x86 at all, due to
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147
> 
> My patch is still waiting for review:
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01280.html

I advise CCing the listed NetBSD target maintainers on your patch 
submission.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Proposal: Improving patch tracking and review using Rietveld

[Joseph S. Myers]

On Fri, 28 Jan 2011, Diego Novillo wrote:

> On Thu, Jan 27, 2011 at 19:44, Joseph S. Myers  
> wrote:
> > On Wed, 26 Jan 2011, Diego Novillo wrote:
> >
> >> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided
> >> the submitter added gcc-patches to the CC list).
> >
> >  appears to be a
> > patch sent using this system where it failed to include the patch in the
> > message to gcc-patches.
> 
> Hm, yes.  I hadn't noticed it because I'm not actually used to the
> patch being included (we conduct reviews on the web interface
> directly).  The issue is with the length of the original patch.  If
> it's too long, it will not include it in the initial message.

The gcc-patches message size limit is 40 bytes.  I don't know exactly 
how that's counted (e.g. whether headers are included), but it should give 
some indication of the appropriate size limit to configure for GCC (I 
presume this is configurable); the patch in question appears to have been 
far below that size.

If a patch (over 400kB) is being excluded from the message because of size 
(and somewhat larger patches could still be included as gzipped 
attachments, though very few patches approach 400kB anyway), it would be 
good for the message to explicitly say so if possible; otherwise it looks 
like an ENOPATCH mistake.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Proposal: Improving patch tracking and review using Rietveld

[Diego Novillo]

On Fri, Jan 28, 2011 at 08:25, Joseph S. Myers  wrote:

> If a patch (over 400kB) is being excluded from the message because of size
> (and somewhat larger patches could still be included as gzipped

I have not looked into upload.py's source code, so I don't know if the
limits are set in the uploader or the server.  I know that the limits
for the description message set by the uploader is ~10kB, but email
replies sent to the issue do not seem to have limits (or they are
<400kB).  I replied to my own patch submission with the original
patch, and the issue was updated without errors.

> attachments, though very few patches approach 400kB anyway), it would be
> good for the message to explicitly say so if possible; otherwise it looks
> like an ENOPATCH mistake.

Technically, Rietveld solves the ENOPATCH problem because the patch is
*always* available at the URL produced in the patch message.  The
easiest way of addressing the lack of patch text in the submission is
to reply to it with the original patch.  But there may be some changes
we can do to upload.py to make this more automatic.  I'll take a look.


Diego.

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

[H.J. Lu]

On Fri, Jan 28, 2011 at 4:52 AM, Laurynas Biveinis
 wrote:
> 2011/1/27 H.J. Lu :
>> I think it is useful. I have run --enable-checking=valgrind once and it
>> took daays to finish.  But I haven't got time analyze the result.
>
> Do you mean, bootstrap + testsuite? IIRC someone submitted a few bug

Yes.

> reports (fixed now) in a row some three years ago which looked like
> testsuite Valgrind failures.
>

It is not me.

-- 
H.J.

Re: Building Secondary Languages After Newlib is Installed

[Joel Sherrill]

On 01/28/2011 04:58 AM, Ralf Corsepius wrote:

On 01/28/2011 10:15 AM, Andreas Schwab wrote:

Ralf Corsepius   writes:


- Remove newlib from the source tree

--without-newlib should probably be enough.

Good point, agreed.

In case of Joel and rtems the situation probably can be furtherly
simplified:

RTEMS has gcc-4.5.5-compiled newlib-rpms - Provided the set of multilibs
hasn't changed (and gcc hasn't changed too much), it probably will
suffice to install these newlib rpms and use them to build gcc against them.


That's true but I want to ensure that the GCC head does indeed
compile newlib and RTEMS with the GCC head.


On 01/28/2011 03:15 AM, Andreas Schwab wrote:

--without-newlib should probably be enough.


This almost works but libstdc++-v3/configure.ac explicitly
checks $with_newlib to trip some AC_DEFINE's which have
to be tripped to build.  I have a patch attached that logically
says if on target X, then you are always using newlib so
if you have "with_newlib" or "use_newlib", then set the
AC_DEFINE's.  There may be a better way to know if the
library installed is newlib.

So if --without-newlib is supposed to do the trick, then
it almost works.  I can build Ada, Go, and C++ with
--without-newlib and this patch or something similar
but better.


Ralf



--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985


Index: libstdc++-v3/configure
===
--- libstdc++-v3/configure  (revision 169331)
+++ libstdc++-v3/configure  (working copy)
@@ -26410,8 +26410,13 @@
   # GLIBCXX_CHECK_MATH_SUPPORT
 
   # First, test for "known" system libraries.  We may be using newlib even
-  # on a hosted environment.
-  if test "x${with_newlib}" = "xyes"; then
+  # on a hosted environment.  Since some environments always use newlib,
+  # we can assume newlib features even if building --without-newlib.
+  case "$target" in
+*-*-rtems*) uses_newlib=yes ;;
+*)  uses_newlib=no ;;
+  esac 
+  if test "x${with_newlib}" = "xyes" -o  "x${uses_newlib}" = "xyes" ; then
 os_include_dir="os/newlib"
 $as_echo "#define HAVE_HYPOT 1" >>confdefs.h
 
Index: libstdc++-v3/configure.ac
===
--- libstdc++-v3/configure.ac   (revision 169330)
+++ libstdc++-v3/configure.ac   (working copy)
@@ -226,8 +226,13 @@
   # GLIBCXX_CHECK_MATH_SUPPORT
 
   # First, test for "known" system libraries.  We may be using newlib even
-  # on a hosted environment.
-  if test "x${with_newlib}" = "xyes"; then
+  # on a hosted environment.  Since some environments always use newlib,
+  # we can assume newlib features even if building --without-newlib.
+  case "$target" in
+*-*-rtems*) uses_newlib=yes ;;
+*)  uses_newlib=no ;;
+  esac 
+  if test "x${with_newlib}" = "xyes" -o  "x${uses_newlib}" = "xyes" ; then
 os_include_dir="os/newlib"
 AC_DEFINE(HAVE_HYPOT)
 

Re: The GNU Compiler Collection should be renamed the Jewish Compiler Collection

[Major Curmudgeon]

Matthew Plant wrote:
> I'm just kidding, I was going to make a joke about being conservative
> about memory but then I realized I would be making fun of my own
> heritage.

Well, there was that glaring bug that caused the compiler to betray
a developer's trust by brutally mangling his private variables when
a certain timestamp became about 8 days old.

In any case, the comedian Doug Stanhope pretty much sums up your email:

http://www.youtube.com/watch?v=MAVyiJ1SINE#t=6m

Re: Building Secondary Languages After Newlib is Installed

[Ian Lance Taylor]

Andreas Schwab  writes:

> Ralf Corsepius  writes:
>
>> - Remove newlib from the source tree
>
> --without-newlib should probably be enough.

But that seems strange to me as some of the configure scripts test for
--with-newlib and adjust their configury accordingly.  This would put
them in a position where they actually are using newlib but are told
that they are not.  It might well be that they will do feature tests and
come up with the right result, but I am frankly skeptical that this will
happen with libstdc++-v3 at least, as it does do specific target tests.

Ian

Re: Building Secondary Languages After Newlib is Installed

[Ralf Corsepius]

On 01/28/2011 04:17 PM, Ian Lance Taylor wrote:

Andreas Schwab  writes:


Ralf Corsepius  writes:


- Remove newlib from the source tree

--without-newlib should probably be enough.

But that seems strange to me as some of the configure scripts test for
--with-newlib and adjust their configury accordingly.  This would put
them in a position where they actually are using newlib but are told
that they are not.  It might well be that they will do feature tests and
come up with the right result, but I am frankly skeptical that this will
happen with libstdc++-v3 at least, as it does do specific target tests.

OK, something in need to be looked into (I haven't in recent times).

However, as RTEMS is defacto tied to newlib and rtems-gccs could be made 
compilable without --with/without-newlib + external newlib.


Ralf

Re: Heads up: please help documenting *internal* GCC changes for 4.6

[Ian Lance Taylor]

Basile Starynkevitch  writes:

> I am not sure to understand what is the social rules to modify that. I
> suppose that any patch to that page should be approved with the same
> strong process as patches to trunk code?

I would say that any gcc maintainer may update the changes file without
explicit review.  The patch must be valid HTML, and Gerald runs a script
which verifies that.  Patches must be sent to gcc-patc...@gcc.gnu.org.

Only make changes that are correct.  If you feel uncertain, you should
get a review.  That review can come from any other gcc maintainer.

(Anyone: please let me know if you disagree with the above.)

> I am not sure to understand the technical ways to modify that; is CVS
> still mandatory?

Yes.

Ian

Re: Heads up: please help documenting *internal* GCC changes for 4.6

[Paul Koning]

On Jan 28, 2011, at 8:04 AM, Laurynas Biveinis wrote:

> 2011/1/28 Basile Starynkevitch :
>>> Its intention is to mention noteworthy internal changes, i.e. changes
>>> interesting for, say, maintainers of backends/frontends outside the
>>> tree, and of course plugin developers upgrading from 4.5 to 4.6.
>>> 
>> 
>> 
>> I am not sure to understand what is the social rules to modify that. I
>> suppose that any patch to that page should be approved with the same
>> strong process as patches to trunk code?
> 
> It needs to be reviewed, but it's much easier IMHO.

I'm wondering if it would be helpful for the internal changes to be documented 
in a separate file, rather than in the same file as the user changes.  That 
makes it more obvious what documentation is being touched.

paul

defining add in a new port

[Jean-Marc Saffroy]

Hi gcc gurus,

I'm trying to port GCC to a new architecture, I'm new to gcc, and have
little problems defining add correctly.

My target has 2 types of (DI mode) registers, so I defined 2 classes:

- class D (data) regs can be used for computations, and that includes
operations such as additions and increments:
reg  += small immediate
 or reg1 += reg2

- class A (address) can be used as base for loads, also they can be
modified with moves (between A-regs and from/to D-regs, not from
immediates) and with increments:
reg += large immediate

So first for adddi3 I have defined the following:

(define_constraint "I"
  "Signed 6-bit integer constant for binops."
  (and (match_code "const_int")
   (match_test "IN_RANGE (ival, -24, 32)")))

(define_register_constraint "A" "ADDR_REGS"
  "The address registers.")

(define_register_constraint "D" "DATA_REGS"
  "The general (data) registers.")

(define_predicate "reg_or_18bit_signed_operand"
  (if_then_else (match_code "const_int")
(match_test "IN_RANGE (INTVAL (op), -(1 << 17), (1 << 17) - 1)")
(match_operand 0 "register_operand")))

(define_insn "adddi3"
  [(set (match_operand:DI 0 "register_operand" "=D,D,A")
(plus:DI
 (match_operand:DI 1 "register_operand" "%0,0,0")
 (match_operand:DI 2 "reg_or_18bit_signed_operand" "I,D,n")))]
  ""
  "@
   addi   %0, %2
   add%0, %2
   adda   %0, %2")

But this doesn't work, I get:

error: insn does not satisfy its constraints:
(insn 1424 1423 141 (set (reg:DI 2 r2)
(plus:DI (reg:DI 2 r2)
(const_int 40 [0x28])))
/home/jmsaffroy/cygnus/src/newlib/libc/time/strptime.c:165 24 {adddi3}
 (expr_list:REG_EQUIV (plus:DI (reg/f:DI 70 a6)
(const_int 40 [0x28]))
(nil)))

(r2 is a D-reg, a6 is an A-reg.)

It seems I was expecting too much intelligence from reload, or I didn't
give enough hints.

So I tried separating the add instructions for A-regs and D-regs into
different patterns with more restrictive predicates for each pattern (so
add for A regs can have large increments), but then I get other ICEs
which I don't understand (first assert in elimination_costs_in_insn fails).

Does anyone have a hint how I should approach this? Is a define_expand
required, or something else?


Cheers,
Jean-Marc

Re: Building Secondary Languages After Newlib is Installed

[Joel Sherrill]

On 01/28/2011 09:17 AM, Ian Lance Taylor wrote:

Andreas Schwab  writes:


Ralf Corsepius  writes:


- Remove newlib from the source tree

--without-newlib should probably be enough.

But that seems strange to me as some of the configure scripts test for
--with-newlib and adjust their configury accordingly.  This would put
them in a position where they actually are using newlib but are told
that they are not.  It might well be that they will do feature tests and
come up with the right result, but I am frankly skeptical that this will
happen with libstdc++-v3 at least, as it does do specific target tests.


libstdc++-v3/configure.ac around line 230:

  # First, test for "known" system libraries.  We may be using newlib even
  # on a hosted environment.
  if test "x${with_newlib}" = "xyes"; then
os_include_dir="os/newlib"
AC_DEFINE(HAVE_HYPOT)


That's where I hacked to say with or using newlib.

As best I can tell, that's the only place.


Ian



--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: Building Secondary Languages After Newlib is Installed

[Ralf Corsepius]

On 01/28/2011 05:48 PM, Joel Sherrill wrote:

On 01/28/2011 09:17 AM, Ian Lance Taylor wrote:

Andreas Schwab  writes:


Ralf Corsepius  writes:


- Remove newlib from the source tree

--without-newlib should probably be enough.

But that seems strange to me as some of the configure scripts test for
--with-newlib and adjust their configury accordingly.  This would put
them in a position where they actually are using newlib but are told
that they are not.  It might well be that they will do feature tests and
come up with the right result, but I am frankly skeptical that this will
happen with libstdc++-v3 at least, as it does do specific target tests.


libstdc++-v3/configure.ac around line 230:

  # First, test for "known" system libraries.  We may be using newlib 
even

  # on a hosted environment.
  if test "x${with_newlib}" = "xyes"; then
os_include_dir="os/newlib"
AC_DEFINE(HAVE_HYPOT)



Yes, I just also noticed this place.

Several details are with this if do not seem right:

a) the hardcoded AC_DEFINE(HAVE_ICONV)
RTEMS doesn't have iconv

b) when using an external newlib binary, the libstdc++'s standard math 
checks should "just work", because modern RTEMS newlib is supposed to 
have most of complex and c99's math.


There are other non-with/without-newlib related issues in 
libstdc++/acinclude.m4 which seem suspicious wrt. RTEMS to me, but I 
haven't investigated in depth, yet.


Ralf

Re: defining add in a new port

[Ian Lance Taylor]

Jean-Marc Saffroy  writes:

> error: insn does not satisfy its constraints:
> (insn 1424 1423 141 (set (reg:DI 2 r2)
> (plus:DI (reg:DI 2 r2)
> (const_int 40 [0x28])))
> /home/jmsaffroy/cygnus/src/newlib/libc/time/strptime.c:165 24 {adddi3}
>  (expr_list:REG_EQUIV (plus:DI (reg/f:DI 70 a6)
> (const_int 40 [0x28]))
> (nil)))

You should find out what is creating this insn.  Is it being created by
reload, or is it being created by some pass that runs after reload?

It is likely that you need to make adddi3 a define_expand which tests
reload_in_progress and reload_completed.  If those are the case, you
will need to explicitly convert
(set (reg:DI DREG1) (plus:DI (reg:DI DREG2) (const_int N)))
into
(set (reg:DI DREG1) (const_int N))
(set (reg:DI DREG1) (plus:DI (reg:DI DREG1) (REG:DI DREG2)))

For a much more sophisticated version of this, see, e.g., addsi3 in the
ARM target.

Ian

Re: NetBSD bootstrap (was: Target deprecations for 4.6)

[MFL Commissioner]

On 1/28/2011 10:32 AM, Jonathan Wakely wrote:

On 28 January 2011 01:11, Joseph S. Myers wrote:

* a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*,
i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd*
not matching vax-*-netbsdelf*).

This implies some x86 targets are expected to work, but NetBSD-current
can't build recent versions of gcc on x86 at all, due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147

My patch is still waiting for review:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01280.html
If it helps, I've been building NetBSD 5.1 and -current with your patch 
without issues.  I removed the workaround that was skipping stddef.h and 
at least the c  and Ada compilers build fine.


John