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 incompatibil
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
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
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-narrow
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: w
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 any
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
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
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
invocat
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.
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
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/rs6
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
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
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 rs
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-
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
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>
>
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
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 with
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_ENVVA
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 s
> 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_LIBR
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, ye
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 agree
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 righ
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-
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++ cla
(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 extension
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 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 bo
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
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
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
34 matches
Mail list logo
