Re: Mips testcase question

2013-07-31 Thread Richard Sandiford
Steve Ellcey  writes:
> On Tue, 2013-07-30 at 20:32 +0100, Richard Sandiford wrote:
>> "Steve Ellcey "  writes:
>> > I have noticed that gcc.target/mips/fpr-moves-7.c and
>> > gcc.target/mips/fpr-moves-8.c fail when running the GCC
>> > testsuite with -msoft-float.
>> 
>> Which configuration and test options are you using and what failure do
>> you see?  It works for me with mipsisa64-elf, so it sounds like it might
>> be configuration-specific.
>> 
>> With your comment about -msym32, I'm guessing you're running -mabi=64 
>> non-PIC,
>> but even mips-sim-idt64/-mabi=64/-msoft-float seems to work with
>> mipsisa64-elf.
>> 
>> Thanks,
>> Richard
>
> It looks like it may be specific to my linux target
> (mips-mti-linux-gnu).  With my elf target (mips-mti-elf), I do not get
> the error.
>
> Here is the error I get when running the testsuite with -msoft-float,
> adding -msym32 to the option list will make the problem go away. Adding
> -fno-pic to the options does not fix the problem.

Thanks, I see it now.  The condition was assuming that if the toolchain
is addressing=absolute by default (as *-linux-gnu is when configured
with --with-mips-plt), mips.exp wouldn't need to do anything to force it
to stay that way.  I'd forgotten that a test that forces -mabi=64 could
switch everything back to flag_pic on these targets.

So yeah, in answer to your original question:

> Should addressing=absolute be set here for soft-float in mips.exp
> or do you think these two tests should just not be run in soft-float mode?

The first, I think.  Or more specifically, we need to do this whenever
-mabicalls is used, rather than just when addressing!=absolute.
Could you give the patch below a try?

Thanks,
Richard


gcc/testsuite/
* gcc.target/mips/mips.exp (mips-dg-options): Test for mabicalls
rather than addressing!=absolute when deciding how to handle MIPS16
when the test forces an ABI.

Index: gcc/testsuite/gcc.target/mips/mips.exp
===
--- gcc/testsuite/gcc.target/mips/mips.exp  2013-07-31 08:01:09.152984085 
+0100
+++ gcc/testsuite/gcc.target/mips/mips.exp  2013-07-31 08:11:18.720738043 
+0100
@@ -1164,7 +1164,7 @@ proc mips-dg-options { args } {
if { [mips_using_mips16_p options]
 && ![mips_same_option_p $abi "-mabi=32"]
 && ![mips_same_option_p $abi "-mabi=o64"]
-&& (![mips_have_option_p options "addressing=absolute"]
+&& ([mips_have_option_p options "-mabicalls"]
 || [mips_have_option_p options "-mhard-float"]) } {
if { [mips_test_option_p options mips16] } {
mips_make_test_option options "addressing=absolute"


Re: New file extension

2013-07-31 Thread Martin Jambor
Hi,

On Tue, Jul 30, 2013 at 11:07:52AM -0500, Gabriel Dos Reis wrote:
> On Tue, Jul 30, 2013 at 7:28 AM, Martin Jambor  wrote:
> 
> > As far as newbies are concerned, I think that grasping that .c files
> > are C++ files is one of the easy things to learn about GCC compared to
> > other necessary knowledge (which is something we should work on).
> 
> One more oddities compared to standard practice.
> 
> > If the problem is that your emacs opens gcc files in C mode instead of
> > C++, add this to your .emacs file:
> >
> > (add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode))
> 
> More oddities: we assume Emacs, and we want people to add those things.
> Are we sure we are worrying about newcomers, or just fighting to preserve
> the way things used to be 20 years?

I am quite sure.  You removed part of my email where I said I would
not mind mass renaming at all if git history was still easily usable.
This is not because I am some sort of crazy conservative, it is
because I use the history very often and I believe I am not alone.

Moreover, after reading Andrew's email in which he outlined a mass
renaming as a part of re-architecting gcc, I believe that waiting for
that to happen and having it happen is the best course of action (even
regardless of inconveniences with git history because that is not
going to be renaming for the sake of renaming but a substantial
change, worth doing nevertheless, or at least I hope so).

In the meantime, people can reconfigure their editor as I do with
emacs.

I still think that mixing C++ .c files and .cc files is silly and more
confusing than what we have now.  However, I can live with it.

As far as newcomers are concerned, I have joined GCC only about 6
years ago so I am still quite new and still remember my earliest days.
>From my experience, the real obstacles are the tough issues to
overcome (like when you have an ICE in expr.c and there is no way you
can understand what is even going on there, let alone why it ICEs),
certainly not a number of small oddities.  If we really want to help
newcomers, we have to concentrate on the difficult stuff.  The simple
things usually do not really matter.

Furthermore, if we do a svn rename here and there, _mechanically_ turn
a struct into a class or a macro into a template (you noted I stressed
the word mechanically, right?) or remove some other small oddity at
the expense of making life of core gcc developers more difficult, the
newcomers will not even notice and the overall outcome will be
negative.  This is not trying to keep things as they were 20 years
ago, this is saying we should only make changes that make sense.  And
personally, I hope I will not only welcome such changes, but also be
able to help with them.

Martin


Re: Mips testcase question

2013-07-31 Thread Steve Ellcey
On Wed, 2013-07-31 at 08:19 +0100, Richard Sandiford wrote:

> The first, I think.  Or more specifically, we need to do this whenever
> -mabicalls is used, rather than just when addressing!=absolute.
> Could you give the patch below a try?
> 
> Thanks,
> Richard

That patch fixed the problem.

Steve Ellcey
sell...@mips.com




Re: fatal error: gnu/stubs-32.h: No such file

2013-07-31 Thread Matthias Klose
Am 29.07.2013 15:06, schrieb FX:
>> As a consensual first step toward addressing this issue, I suggest the 
>> following patch to the doc. I hope it is clear enough, but suggestions are 
>> obviously welcome. (I haven't even compiled the docs with it, as I'm on my 
>> laptop with little battery.)
> 
> Given that I received no feedback, I'd like to submit this doc patch 
> formally. Tested by doing "make info html pdf".
> OK to commit to trunk? What about other active release branches?

if you mention distribution specific packages, please add the ones needed for
some distributions. For Debian/Ubuntu this would be g++-multilib if the
architecture is multilib'ed, g++ otherwise.

  Matthias



Re: fatal error: gnu/stubs-32.h: No such file

2013-07-31 Thread Jonathan Wakely
On 31 July 2013 20:44, Matthias Klose wrote:
> if you mention distribution specific packages, please add the ones needed for
> some distributions. For Debian/Ubuntu this would be g++-multilib if the
> architecture is multilib'ed, g++ otherwise.

That's not the package that provides gnu/stubs-32.h, is it?  I thought
it was something like libc6-dev-i386?  Please correct
http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h if I'm wrong.


Re: fatal error: gnu/stubs-32.h: No such file

2013-07-31 Thread Russ Allbery
Jonathan Wakely  writes:
> On 31 July 2013 20:44, Matthias Klose wrote:

>> if you mention distribution specific packages, please add the ones needed for
>> some distributions. For Debian/Ubuntu this would be g++-multilib if the
>> architecture is multilib'ed, g++ otherwise.

> That's not the package that provides gnu/stubs-32.h, is it?  I thought
> it was something like libc6-dev-i386?  Please correct
> http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h if I'm wrong.

gcc-multilib and g++-multilib depend on all the various packages that you
need to have.  They will, among other things, install libc6-dev-i386.  For
example, on a current wheezy system, you will see the following dependency
chain:

gcc-multilib -> gcc-4.7-multilib -> libc6-dev-i386

but also various other things like lib32gcc1.

-- 
Russ Allbery (r...@stanford.edu)