libstdc++ breaks bootstrap (at least on x86_64-darwin11, maybe more)

[FX]

I've filed PR 51026  (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026). In 
the meantime, how do I build "the old way", with just a C compiler? I tried to 
configure with "--enable-languages=c,fortran --disable-build-with-cxx", but the 
configure script still says:

> The following languages will be built: c,c++,fortran


Thanks!
FX

Re: libstdc++ breaks bootstrap (at least on x86_64-darwin11, maybe more)

[Tobias Burnus]

On 11/08/2011 09:10 AM, FX wrote:
> I've filed PR 51026 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026). In the meantime, 
how do I build "the old way", with just a C compiler? I tried to 
configure with "--enable-languages=c,fortran --disable-build-with-cxx", 
but the configure script still says:

>
>> The following languages will be built: c,c++,fortran

You could try: --disable-build-poststage1-with-cxx

Tobias

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

[David Brown]

On 08/11/2011 05:27, Hans-Peter Nilsson wrote:

On Sun, 6 Nov 2011, Joern Rennecke wrote:


Quoting David Brown:


Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc).  It has an instruction will
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
16-bit integer - basically combining an 8-bit x 8-bit to 16-bit
multiply with a left shift.  So to do a "signed short _Fract" multiply,
you have a single instruction and discard the least significant byte.

Simulating the same operation in generic C would be something like :

int8_t multShortFract(int8_t a, int8_t b) {
int16_t c = (int16_t) a * b;
return (c>>  7);
}


If you can make up your mind if the result is 8 or 16 bit, generating the
instruction should be standard fare for the combiner pass.




If the compiler can generate fractional arithmetic code directly from 
such expressions, then it is indeed a good step towards implementing 
such types as a pure C++ class without needing to use compiler extensions.


However, this is a simple case.  It gets a lot more complicated with 
"_Accum" types, with saturating types, and especially when mixing them. 
 It also gets more complicated when you start to have series of 
expressions, constant folding, etc.  I am not saying the compiler 
couldn't generate optimal code (on a target with hardware support for 
these operations) out from carefully written generic C++ code - but I do 
think it would be easier to get good code if the compiler views these 
types as "native".


The guts of gcc already know about types like "signed short _Fract", and 
can handle them well (at least for some targets).  It is always easier 
for the compiler when it has more knowledge than if it has to guess 
based on code patterns - so using "signed short _Fract" means it can see 
the real type early in the process rather than in a later "combine" pass.



Looks like a pretty typical Q7 (or Q1.7) multiplication to me
unless I miss something...  Would be a nice thing to have those
Q1.  formats as native GCC-extension types including
vectorized versions.  No, not planning it.



Yes, it is Q1.7 multiplication.  And there is already a type for it in 
C, though gcc doesn't (yet) support it for all targets (I haven't 
checked recent versions).  It is "signed short _Fract" from TR 18037.




And having intermediate calculations in a wider mode does not
constituate lack of making ones mind up. :)


Correct - the return type is clearly int8_t.  The wider intermediate 
mode is a necessity of C.



Though I believe that cast of "a" is ineffective, IIUC.



Also correct - "a" will be promoted automatically to an "int" (which is 
always at least 16-bit).  From long habit in embedded programming, I 
tend to be a bit more explicit about such conversions.  A real-world 
library would be written somewhat differently, of course (at the very 
least, it would use "int_fast16_t").



brgds, H-P

transactional-memory branch has been merged into trunk

[Aldy Hernandez]

The TM branch has been merged into trunk.  No regressions or problems 
when testing on x86-64 Linux.


Thanks to Torvald and Richard for all their hard work this past week 
(and prior!).  And thanks to all the branch reviewers.


If anyone needs me, I'll be enjoying my time in Honolulu, so don't bother!

GCC 4.7.0 Status Report (2011-11-08), Stage 1 is over, Stage 3 in effect immediately

[Jakub Jelinek]

Status
==

The GCC trunk is now in stage3, even TM branch has been merged
during the last minute, patches submitted during stage1
may be still accepted, if they don't need significant rewrites,
but please try to get them in soon.  Otherwise only bugfixes
and documentation fixes are allowed for the trunk.
If all goes well, stage3 would again as last time go on for roughly
two months, with the aim of getting the release at the end of
March to mid April.

We have accumulated quite a lot of bugs during the almost 8 months
long stage 1, please help with analysing them and bugfixing.


Quality Data


Priority  #   Change from Last Report
---   ---
P1   46   + 15
P2   99   - 10
P3   24   -  4
---   ---
Total   169   +  1


Previous Report
===

http://gcc.gnu.org/ml/gcc/2011-10/msg00481.html

The next report will be sent by Joseph.

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

[Hans-Peter Nilsson]

(Not CC:ing the quoted newsgroup, sorry.)

On Tue, 8 Nov 2011, David Brown wrote:
> If the compiler can generate fractional arithmetic code directly from such
> expressions, then it is indeed a good step towards implementing such types as
> a pure C++ class without needing to use compiler extensions.

Right, but don't hold your breath.  Getting a native type in
place for all targets seems to be more important.

> The guts of gcc already know about types like "signed short _Fract", and can
> handle them well (at least for some targets).

By default too few to matter, it seems, MIPS and ARM.  Not even
sure any of it works elsewhere.  Missing from the AVR port too
(yes, that's you cue. :)  For acceptance, IMHO better get it
working universally by open-coding the implementation without
requiring --enable-* options.

>  It is always easier for the
> compiler when it has more knowledge than if it has to guess based on code
> patterns - so using "signed short _Fract" means it can see the real type early
> in the process rather than in a later "combine" pass.

Certainly.

> > Looks like a pretty typical Q7 (or Q1.7) multiplication to me
> > unless I miss something...  Would be a nice thing to have those
> > Q1.  formats as native GCC-extension types including
> > vectorized versions.  No, not planning it.
> >
>
> Yes, it is Q1.7 multiplication.  And there is already a type for it in C,
> though gcc doesn't (yet) support it for all targets (I haven't checked recent
> versions).

I checked my tree above (up-to-date modulo a few hours).

>  It is "signed short _Fract" from TR 18037.
> 

There you go!  I thought it had other semantics.  Actually the
type would be target-dependent, but all the targets (both ARM
and MIPS :) have it that way.  Somewhat awkward: the intuitive
choice would have been "signed char _Fract" IMHO.

brgds, H-P

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

[David Brown]

On 08/11/2011 15:24, Hans-Peter Nilsson wrote:

(Not CC:ing the quoted newsgroup, sorry.)

On Tue, 8 Nov 2011, David Brown wrote:

If the compiler can generate fractional arithmetic code directly from such
expressions, then it is indeed a good step towards implementing such types as
a pure C++ class without needing to use compiler extensions.


Right, but don't hold your breath.  Getting a native type in
place for all targets seems to be more important.


Agreed.




The guts of gcc already know about types like "signed short _Fract", and can
handle them well (at least for some targets).


By default too few to matter, it seems, MIPS and ARM.  Not even
sure any of it works elsewhere.  Missing from the AVR port too
(yes, that's you cue. :)  For acceptance, IMHO better get it
working universally by open-coding the implementation without
requiring --enable-* options.



Agreed.

I had actually thought the fixed point types were part of the 
up-and-coming C1x standard, but it seems they are not - they are just 
part of a draft "TR 18037".  Maybe that will make it into the C 
standards eventually.


I had been thinking that since they are in a C standard, it's only a 
matter of time before gcc supports them on all targets.



  It is always easier for the
compiler when it has more knowledge than if it has to guess based on code
patterns - so using "signed short _Fract" means it can see the real type early
in the process rather than in a later "combine" pass.


Certainly.


Looks like a pretty typical Q7 (or Q1.7) multiplication to me
unless I miss something...  Would be a nice thing to have those
Q1.   formats as native GCC-extension types including
vectorized versions.  No, not planning it.



Yes, it is Q1.7 multiplication.  And there is already a type for it in C,
though gcc doesn't (yet) support it for all targets (I haven't checked recent
versions).


I checked my tree above (up-to-date modulo a few hours).


  It is "signed short _Fract" from TR 18037.



There you go!  I thought it had other semantics.  Actually the
type would be target-dependent, but all the targets (both ARM
and MIPS :) have it that way.  Somewhat awkward: the intuitive
choice would have been "signed char _Fract" IMHO.



I can understand why you say that - but from my point of view, "signed 
char _Fract" is as horrible as "signed short _Fract".  What is really 
needed is an equivalent to "stdint.h" to give specific, fixed sizes to 
these - then programmers can rely on them.  Something like


typedef signed short _Fract fract1q7;
typedef unsigned short _Fract ufract0q7;

Otherwise there will be more madness in the ranks of embedded programmers...


Actually, I suspect that the reality of the situation is that the time 
for these types has gone.  They will be useful to a few, but people will 
continue to use their ugly, type-unsafe, macro-ridden, target-specific 
fixed point libraries - either written themselves or by the manufacturer 
of the target chip.  Steadily more chips support single-precision 
floating point in hardware, making fixed point redundant for many uses. 
 I still think it would be nice to see full support in gcc - both for C 
and C++.  But I think that by the time they are well supported on a 
range of compilers and targets, and therefore useful for general 
portable embedded code, most code that could use them will use floating 
point in stead.




brgds, H-P

Re: libgcc/static-object.mk weird error on powerpc-rtems

[Dave Korn]

On 04/11/2011 17:33, Joel Sherrill wrote:
> Hi,
> 
> I am testing powerpc-rtems on the head and
> have gotten a weird error compiling libgcc.
> It is definitely a regression from 4.6.
> I have no idea who might be the best person
> to help resolve this.
> 
> /home2/joel/build/b-powerpc-gcc/powerpc-rtems4.11/libgcc
> [joel@rtbf64a libgcc]$ make
> /users/joel/test-gcc/gcc-svn/libgcc/static-object.mk:18: *** Unsupported
> file type: .  Stop.
> 
> Playing with the error message, it looks like
> the "$o" in the message is empty.
> 
> What can I pass along to help get this debugged?

  Still having trouble with this?  Try the makefile debugger:

http://bashdb.sourceforge.net/remake/

  You can step through the libgcc makefile and see where the empty entry comes
from or just turn on enough tracing to see the return values from every string
function executed.

  It may turn out to be stray whitespace in one of LIB2ADD, LIB2ADD_ST,
LIB2ADDEHSTATIC, LIB2ADDEHSHARED, LIB2ADDEH or LIBUNWIND that needs trimming
with $(strip).

cheers,
  DaveK

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

[Joseph S. Myers]

On Tue, 8 Nov 2011, David Brown wrote:

> The guts of gcc already know about types like "signed short _Fract", and can
> handle them well (at least for some targets).  It is always easier for the

Actually, I'd say they are handled badly.  The approach of separate 
machine modes for them going right into the back end is not a good 
approach at all; at an appropriate point, fixed-point *types* should be 
lowered to fixed-point *operations* on generic types (some would just be 
existing operations, some would be saturating operations, some would be 
multiply-and-shift).  See the discussion of the ARM fixed-point support 
; duplicating 
(for every target) support for implementing a fixed-point operation using 
a generic integer operation is not sensible.

(Fractional types do make sense as an API; treating saturation as a type 
property rather than an operation property is a more doubtful aspect of TR 
18037.  But in both cases there should be a lowering pass.)

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

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

[Joseph S. Myers]

On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:

> (yes, that's you cue. :)  For acceptance, IMHO better get it
> working universally by open-coding the implementation without
> requiring --enable-* options.

Making something involving new types - and so ABI impact - universal 
without actually agreeing the ABI for each target with appropriate ABI 
maintainers or interest groups for that target is not a good idea.  It 
leads to ABI incompatibility with other compilers, and to inefficient and 
poorly specified ABIs that are "whatever GCC happens to implement if you 
don't think about it" like we have on several targets for complex 
types  (I spent quite some time reverse engineering and documenting 
the peculiarities of the ABIs for 32-bit Power GNU/Linux that arose in 
that way; now documented in the Power.org ABI specification.)

(It is however desirable that supporting fixed point or decimal floating 
point for a new target ought not to require more from that target than 
appropriate definitions of the ABI.)

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

Re: AIX library issues

[David Edelsohn]

On Tue, Oct 25, 2011 at 10:26 AM, Arnaud Charlet  wrote:
>> > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which
>> > allows us in particular to use dwarf-2/3 debug info.
>>
>> Is AdaCore maintaining GNU Binutils on AIX?
>
> We're "maintaining" it sufficiently for our needs, yes.
>
>> I do not believe that
>> Binutils implements some toolchain changes to AIX 6.1 and AIX 7.1.
>
> That's quite possible. Currently we support AIX 5.2 and 5.3, so haven't
> encountered AIX 6.x or 7.x specific issues.
>
> Do you know if these toolchain changes are significant?

AIX now supports DWARF debugging with XCOFF object files.  XCOFF also
has a new XCOFF_DEP_EXEMPT flag to override the default stack
execution disabled.  There are a lot of little changes for new AIX
features.

The bigger problem is GDB no longer is able to debug cc1plus on the
trunk and GCC now builds as C++ by default.

Thanks, David

Re: gcc-trunk build error in OpenBSD on stage3

[niXman]

> Why is this failing on your system?
Up to now, I've been building GCC on a different machine (the OS
wasn't installed by me). Now, I have installed OpenBSD-5.0 on the VM.


> Look for uses of RPATH_ENVVAR in the top level Makefile.
This line from Makefile:
RPATH_ENVVAR = LD_LIBRARY_PATH


LD_LIBRARY_PATH set to /usr/local/lib
prefix for GCC - /usr/local

gnatmake unhandled argument

[Joel Sherrill]

Hi,

I don't seem to be able to track this down.

make[3]: Entering directory `/home2/joel/build/b-sparc-ada/gcc/ada/tools'
gnatmake -j0 
-I/usr/lib/gcc/x86_64-redhat-linux/4.5.1/adalib/../adainclude 
-I/usr/lib/gcc/x86_64-redhat-linux/4.5.1/adalib/ -I. 
-I/users/joel/test-gcc/gcc-svn/gcc/ada -u sdefault --GCC="gcc "

gnatmake: numeric value out of range for switch: j

The "numeric value out of range" is coming from a support
routine and I don't see where it is called.

FWIW I think this is the -jN argument to make being passed through
to gnatmake.

--
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: gcc-trunk build error in OpenBSD on stage3

[Ian Lance Taylor]

niXman  writes:

>> Why is this failing on your system?
> Up to now, I've been building GCC on a different machine (the OS
> wasn't installed by me). Now, I have installed OpenBSD-5.0 on the VM.
>
>
>> Look for uses of RPATH_ENVVAR in the top level Makefile.
> This line from Makefile:
> RPATH_ENVVAR = LD_LIBRARY_PATH
>
>
> LD_LIBRARY_PATH set to /usr/local/lib
> prefix for GCC - /usr/local

Thanks, but I'm trying to give you hints for how to debug this yourself.

I can't debug it for you.

Ian

template class with default parameter in template parameter declaration

[Ulrich Drepper]

Complicated title, here's a bit of code:

#ifdef FIX
# define PARM2 , class T5
#else
# define PARMS2
#endif


template
struct cl1 {
};

template class T4 = cl1>
struct cl2 {
};

cl2<> var;

If compiled without FIX defined this will fail with gcc 4.3 and later.
 Haven't checked 4.2 but it works without the fix with gcc 4.1.  The
strange thing is that it also worked with ancient compilers before the
C++ frontend rewrite (gcc 3.2).  In short, when a expecting a template
class in a template parameter list it now is not possible anymore to
skip the default parameters.  Since this is an actual use of the class
(in case the default is used) and the programmer declares to have no
interest in the type of the second template parameter I wouldn't say
it is needed but I haven't tracked a statement in the standard.

Before changing too much code I want to make sure this new and very
old behavior is what is required by the standard and not a bug which
slipped in again.

Re: template class with default parameter in template parameter declaration

[Marc Glisse]

On Tue, 8 Nov 2011, Ulrich Drepper wrote:


Complicated title, here's a bit of code:

#ifdef FIX
# define PARM2 , class T5
#else
# define PARMS2
#endif


template
struct cl1 {
};

template class T4 = cl1>
struct cl2 {
};

cl2<> var;

If compiled without FIX defined this will fail with gcc 4.3 and later.
Haven't checked 4.2 but it works without the fix with gcc 4.1.  The
strange thing is that it also worked with ancient compilers before the
C++ frontend rewrite (gcc 3.2).  In short, when a expecting a template
class in a template parameter list it now is not possible anymore to
skip the default parameters.  Since this is an actual use of the class
(in case the default is used) and the programmer declares to have no
interest in the type of the second template parameter I wouldn't say
it is needed but I haven't tracked a statement in the standard.

Before changing too much code I want to make sure this new and very
old behavior is what is required by the standard and not a bug which
slipped in again.


It is announced in:
http://gcc.gnu.org/gcc-4.2/changes.html

It broke quite a bit of code (in particular with std::vector as cl1), but 
there were some exotic pieces of legal code that were broken by this 
extension, so it had to go.


--
Marc Glisse

Re: template class with default parameter in template parameter declaration

[Andrew Pinski]

On Tue, Nov 8, 2011 at 10:53 AM, Marc Glisse  wrote:
> On Tue, 8 Nov 2011, Ulrich Drepper wrote:
>
>> Complicated title, here's a bit of code:
>>
>> #ifdef FIX
>> # define PARM2 , class T5
>> #else
>> # define PARMS2
>> #endif
>>
>>
>> template
>> struct cl1 {
>> };
>>
>> template class T4 = cl1>
>> struct cl2 {
>> };
>>
>> cl2<> var;
>>
>> If compiled without FIX defined this will fail with gcc 4.3 and later.
>> Haven't checked 4.2 but it works without the fix with gcc 4.1.  The
>> strange thing is that it also worked with ancient compilers before the
>> C++ frontend rewrite (gcc 3.2).  In short, when a expecting a template
>> class in a template parameter list it now is not possible anymore to
>> skip the default parameters.  Since this is an actual use of the class
>> (in case the default is used) and the programmer declares to have no
>> interest in the type of the second template parameter I wouldn't say
>> it is needed but I haven't tracked a statement in the standard.
>>
>> Before changing too much code I want to make sure this new and very
>> old behavior is what is required by the standard and not a bug which
>> slipped in again.
>
> It is announced in:
> http://gcc.gnu.org/gcc-4.2/changes.html
>
> It broke quite a bit of code (in particular with std::vector as cl1), but
> there were some exotic pieces of legal code that were broken by this
> extension, so it had to go.

To expand on that
http://gcc.gnu.org/gcc-4.1/changes.html
Says it was an undocumented extension which was depercated in 4.1 and
will be removed in a later version.
Thanks,
Andrew Pinski

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

[Hans-Peter Nilsson]

On Tue, 8 Nov 2011, Joseph S. Myers wrote:
> On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:
>
> > (yes, that's you cue. :)  For acceptance, IMHO better get it
> > working universally by open-coding the implementation without
> > requiring --enable-* options.
>
> Making something involving new types - and so ABI impact - universal
> without actually agreeing the ABI for each target with appropriate ABI
> maintainers or interest groups for that target is not a good idea.  It
> leads to ABI incompatibility with other compilers, and to inefficient and
> poorly specified ABIs that are "whatever GCC happens to implement if you
> don't think about it" like we have on several targets for complex
> types

I'd hope ABI issues would be solved trivially by mapping to the
same-sized integer type, the one ISTR you mentioned would be a
good idea to keep before lowering the operations ;) but I guess
I see your point.

brgds, H-P

Re: how to configure for libitm?

[Torvald Riegel]

On Thu, 2011-11-03 at 16:50 -0400, Jack Howarth wrote:
> I am trying to test the proposed merge of the transactional memory branch on
> x86_64-apple-darwin11. Since the posted patches on gcc-patches seem to have 
> malformed sections, I used the merge patches from 
> http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/
> instead (with the adjustment of moving the patch for crtstuff.c from gcc to 
> libgcc).
> However I don't see able to get libitm to build. The configure changes don't 
> seem to have
> any explicit transactional memory options and --enable-libitm seems to be 
> ignored.
> From the changes in configure.ac, darwin should be a supported target. Thanks 
> in
> advance for any clues.

Can you please try again with trunk? We changed a few configury bits. I
don't have access to any Darwin system.

Thanks,
Torvald

Re: powerpc rs6000_explicit_options change help request

[David Edelsohn]

On Mon, Nov 7, 2011 at 10:44 PM, Joel Sherrill
 wrote:
> Hi,
>
> powerpc-rtems does not compile on the head due
> to what appear to be changes in the way CPU
> features are represented for the arguments.
>
> The compilation error is:
>
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c -o rs6000.o
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c: In function
> ‘rs6000_option_override_internal’:
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3: error:
> ‘rs6000_explicit_options’ undeclared (first use in this function)
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3: note: each
> undeclared identifier is reported only once for each function it appears in

It looks like this was missed by Joseph during his change.

- David

Re: libgcc/static-object.mk weird error on powerpc-rtems

[Michael Meissner]

On Fri, Nov 04, 2011 at 12:33:35PM -0500, Joel Sherrill wrote:
> Hi,
> 
> I am testing powerpc-rtems on the head and
> have gotten a weird error compiling libgcc.
> It is definitely a regression from 4.6.
> I have no idea who might be the best person
> to help resolve this.
> 
> /home2/joel/build/b-powerpc-gcc/powerpc-rtems4.11/libgcc
> [joel@rtbf64a libgcc]$ make
> /users/joel/test-gcc/gcc-svn/libgcc/static-object.mk:18: ***
> Unsupported file type: .  Stop.
> 
> Playing with the error message, it looks like
> the "$o" in the message is empty.
> 
> What can I pass along to help get this debugged?

I've seen this in the past.  Typically what happened is the compiler did not
build, but in some cases it still tried to build libgcc.  First make sure the
compiler built (going into the gcc subdirectory and saying make).  When I'm
doing this, I tend to prefer eliminating any -j options so that it is clearer
what is going on.

To simplify things that break in libgcc, I often times just configure for C
only, just to save the build time.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Michael Meissner]

On Sun, Nov 06, 2011 at 07:18:52AM +0100, Ralf Corsepius wrote:
> Hi,
> 
> Since recently, I am facing several of the warnings above when
> building GCC-trunk cross for RTEMS targets.
> 
> So far, not much clues about what is going on, except that I see
> -Wno-narrowing were recently added to
> gcc/configure.ac and libcpp/configure.ac.

FWIW, I'm seeing it also when I'm building on x86_64 RHEL 6.1 targeting
powerpc64-linux, so I suspect it is a cross compiler issue, but I haven't
checked it in detail.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: powerpc rs6000_explicit_options change help request

[Michael Meissner]

On Mon, Nov 07, 2011 at 09:44:25PM -0600, Joel Sherrill wrote:
> Hi,
> 
> powerpc-rtems does not compile on the head due
> to what appear to be changes in the way CPU
> features are represented for the arguments.
> 
> The compilation error is:
> 
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c -o rs6000.o
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c: In function
> ‘rs6000_option_override_internal’:
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3:
> error: ‘rs6000_explicit_options’ undeclared (first use in this
> function)
> /users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3:
> note: each undeclared identifier is reported only once for each
> function it appears in
> At top level:
> 
> The code is in rtems.h is currently:
> 
> if (TARGET_E500) \
> { \
> if (TARGET_HARD_FLOAT && !rs6000_explicit_options.float_gprs) \
> rs6000_float_gprs = 1; \
> if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe) \
> rs6000_spe = 1; \
> if (rs6000_spe && !rs6000_explicit_options.spe_abi) \
> rs6000_spe_abi = 1; \
> } \
> 
> I think that changes to something like:
> 
> if (TARGET_E500) \
> { \
> if (!global_options_set.x_rs6000_float_gprs) \
> rs6000_float_gprs = 1; \
> if (!global_options_set.x_rs6000_spe) \
> rs6000_spe = 1; \
> if (!global_options_set.x_rs6000_spe_abi) \
> rs6000_spe_abi = 1; \
> } \
> 
> That compiles but I wanted a sanity check that it is the right
> transformation.

Yes, this is the right transformation.  Here is an untested patch that fixes
it:

2011-11-08  Michael Meissner  

* config/rs6000/rtems.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Use
global_options_set instead of rs6000_explicit_options, which was
removed on May 5th.

Index: gcc/config/rs6000/rtems.h
===
--- gcc/config/rs6000/rtems.h   (revision 181174)
+++ gcc/config/rs6000/rtems.h   (working copy)
@@ -61,11 +61,11 @@
   do { \
 if (TARGET_E500)   \
   {
\
-if (TARGET_HARD_FLOAT && !rs6000_explicit_options.float_gprs)  \
+if (TARGET_HARD_FLOAT && !global_options_set.x_float_gprs) \
   rs6000_float_gprs = 1;   \
-if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe)\
+if (rs6000_float_gprs != 0 && !global_options_set.x_spe)   \
   rs6000_spe = 1;  \
-if (rs6000_spe && !rs6000_explicit_options.spe_abi)\
+if (rs6000_spe && !global_options_set.x_spe_abi)   \
   rs6000_spe_abi = 1;  \
   }
\
   } while(0)

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Jonathan Wakely]

On 8 November 2011 19:29, Michael Meissner wrote:
> On Sun, Nov 06, 2011 at 07:18:52AM +0100, Ralf Corsepius wrote:
>> Hi,
>>
>> Since recently, I am facing several of the warnings above when
>> building GCC-trunk cross for RTEMS targets.
>>
>> So far, not much clues about what is going on, except that I see
>> -Wno-narrowing were recently added to
>> gcc/configure.ac and libcpp/configure.ac.
>
> FWIW, I'm seeing it also when I'm building on x86_64 RHEL 6.1 targeting
> powerpc64-linux, so I suspect it is a cross compiler issue, but I haven't
> checked it in detail.

I saw it on a native build, possibly netbsd, but I ignored it as I was
in the middle of something.  Will keep an eye out for it again.

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Jason Merrill]

On 11/08/2011 03:08 PM, Jonathan Wakely wrote:

I saw it on a native build, possibly netbsd, but I ignored it as I was
in the middle of something.  Will keep an eye out for it again.


I see it occasionally too, but haven't been able to reproduce it when 
calling the compiler directly.  Very odd.


Jason

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Paolo Carlini]

Hi,

> I saw it on a native build, possibly netbsd, but I ignored it as I was
> in the middle of something.  Will keep an eye out for it again.

I believe that the core issue is pretty clear: -Wno-narrowing disables a C++ 
only warning but somehow we are passing it also in a few C compiler 
invocations, thus the driver warns. We could suppress such warnings too ;) or 
special case those files?

Paolo

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Jason Merrill]

On 11/08/2011 03:22 PM, Paolo Carlini wrote:

I believe that the core issue is pretty clear: -Wno-narrowing disables a C++ 
only warning but somehow we are passing it also in a few C compiler 
invocations, thus the driver warns.


No, it's accepted by the C front end too, it just has no effect.  It's 
listed as a C option in c.opt.  But during builds cc1 warns about it 
sometimes and not others.  It's very odd.


Jason

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Paolo Carlini]

Hi,

> On 11/08/2011 03:22 PM, Paolo Carlini wrote:
>> I believe that the core issue is pretty clear: -Wno-narrowing disables a C++ 
>> only warning but somehow we are passing it also in a few C compiler 
>> invocations, thus the driver warns.
> 
> No, it's accepted by the C front end too, it just has no effect.

I see. Actually I'm clear about the no effect thing and also that the warning 
isn't really worrisome. But I thought that  the front end in general warns for 
such no effects warnings. I didn't really study the relevant code, to be honest.

Paolo

Re: transactional-memory branch has been merged into trunk

[Andrew Pinski]

On Tue, Nov 8, 2011 at 3:19 AM, Aldy Hernandez  wrote:
> The TM branch has been merged into trunk.  No regressions or problems when
> testing on x86-64 Linux.
>
> Thanks to Torvald and Richard for all their hard work this past week (and
> prior!).  And thanks to all the branch reviewers.
>
> If anyone needs me, I'll be enjoying my time in Honolulu, so don't bother!

And this breaks x86 builds with semi-older binutils.  Binutils without
AVX support gives the following error message while build libtm:
/usr/bin/as: unrecognized option `-msse2avx'

I think someone needs to update the requirements part of install.texi
or better yet not require such a new binutils.

Thanks,
Andrew Pinski

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Andreas Schwab]

Jason Merrill  writes:

> No, it's accepted by the C front end too, it just has no effect.  It's
> listed as a C option in c.opt.  But during builds cc1 warns about it
> sometimes and not others.  It's very odd.

$ gcc -Wno-narrowing -c hello.c 
$ gcc -Wno-narrowing -c hello.c -Wall
hello.c:14:1: warning: return type defaults to ‘int’
cc1: warning: unrecognized command line option "-Wno-narrowing"

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

[Andreas Schwab]

Andreas Schwab  writes:

> Jason Merrill  writes:
>
>> No, it's accepted by the C front end too, it just has no effect.  It's
>> listed as a C option in c.opt.  But during builds cc1 warns about it
>> sometimes and not others.  It's very odd.
>
> $ gcc -Wno-narrowing -c hello.c 
> $ gcc -Wno-narrowing -c hello.c -Wall
> hello.c:14:1: warning: return type defaults to ‘int’
> cc1: warning: unrecognized command line option "-Wno-narrowing"

/* Buffer the unknown option described by the string OPT.  Currently,
   we only complain about unknown -Wno-* options if they may have
   prevented a diagnostic. Otherwise, we just ignore them.  Note that
   if we do complain, it is only as a warning, not an error; passing
   the compiler an unrecognised -Wno-* option should never change
   whether the compilation succeeds or fails.  */

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

gcc-4.4-20111108 is now available

[gccadmin]

Snapshot gcc-4.4-2008 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-2008/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 181180

You'll find:

 gcc-4.4-20111108.tar.bz2 Complete GCC

  MD5=5cbb7c0785bcd1561d3a1a1f43abbb7f
  SHA1=6012f694501428356514d4a125a4ae489c3b45d4

Diffs from 4.4-2001 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: transactional-memory branch has been merged into trunk

[Jonathan Wakely]

On 8 November 2011 22:01, Andrew Pinski wrote:
>
> And this breaks x86 builds with semi-older binutils.  Binutils without
> AVX support gives the following error message while build libtm:
> /usr/bin/as: unrecognized option `-msse2avx'

Is that related to this bootstrap failure I'm seeing on netbsd with
binutils 2.16.1?

gmake[5]: Leaving directory
`/home/jwakely/build/x86_64-unknown-netbsd5.1/libitm'
mv -f .deps/x86_sse.Tpo .deps/x86_sse.Plo
/var/tmp//ccNOphzJ.s: Assembler messages:
/var/tmp//ccNOphzJ.s:14: Error: no such instruction: `vpalignr
$1,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:17: Error: no such instruction: `vpalignr
$2,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:20: Error: no such instruction: `vpalignr
$3,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:23: Error: no such instruction: `vpalignr
$4,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:26: Error: no such instruction: `vpalignr
$5,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:29: Error: no such instruction: `vpalignr
$6,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:32: Error: no such instruction: `vpalignr
$7,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:35: Error: no such instruction: `vpalignr
$8,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:38: Error: no such instruction: `vpalignr
$9,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:41: Error: no such instruction: `vpalignr
$10,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:44: Error: no such instruction: `vpalignr
$11,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:47: Error: no such instruction: `vpalignr
$12,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:50: Error: no such instruction: `vpalignr
$13,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:53: Error: no such instruction: `vpalignr
$14,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:56: Error: no such instruction: `vpalignr
$15,%xmm0,%xmm1,%xmm0'
/var/tmp//ccNOphzJ.s:110: Error: no such instruction: `vmovaps 16(%rsp),%ymm0'
/var/tmp//ccNOphzJ.s:164: Error: no such instruction: `vmovaps 16(%rsp),%ymm0'
/var/tmp//ccNOphzJ.s:218: Error: no such instruction: `vmovaps 16(%rsp),%ymm0'
/var/tmp//ccNOphzJ.s:272: Error: no such instruction: `vmovaps 16(%rsp),%ymm0'
/var/tmp//ccNOphzJ.s:297: Error: no such instruction: `vmovaps %ymm0,32(%rsp)'
/var/tmp//ccNOphzJ.s:324: Error: no such instruction: `vzeroupper'
/var/tmp//ccNOphzJ.s:351: Error: no such instruction: `vmovaps %ymm0,32(%rsp)'
/var/tmp//ccNOphzJ.s:378: Error: no such instruction: `vzeroupper'
/var/tmp//ccNOphzJ.s:405: Error: no such instruction: `vmovaps %ymm0,32(%rsp)'
/var/tmp//ccNOphzJ.s:432: Error: no such instruction: `vzeroupper'
gmake[4]: *** [x86_avx.lo] Error 1
gmake[4]: *** Waiting for unfinished jobs

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

[Joseph S. Myers]

On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:

> > Making something involving new types - and so ABI impact - universal
> > without actually agreeing the ABI for each target with appropriate ABI
> > maintainers or interest groups for that target is not a good idea.  It
> > leads to ABI incompatibility with other compilers, and to inefficient and
> > poorly specified ABIs that are "whatever GCC happens to implement if you
> > don't think about it" like we have on several targets for complex
> > types
> 
> I'd hope ABI issues would be solved trivially by mapping to the
> same-sized integer type, the one ISTR you mentioned would be a
> good idea to keep before lowering the operations ;) but I guess
> I see your point.

The ABI also needs to say which is the same-sized type - and how many 
integer and fractional bits there are - and there's no guarantee that the 
psABI maintainers will actually make it behave like the same-sized integer 
type.

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