4.3 trunk revision 126185 I got at x86_64:
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
make[6]: *** [kill.lo] Error 1
Anyone else got the same?
126184 passes. Looks like problems in this check:
r126185 | kargl | 2007-07-02 10:47:21 +0800 (M
> 4.3 trunk revision 126185 I got at x86_64:
>
> libtool: compile: unable to infer tagged configuration
> libtool: compile: specify a tag with `--tag'
> make[6]: *** [kill.lo] Error 1
>
> Anyone else got the same?
Yes, but resync your tree and this will be gone.
--
Eric Botcazou
The new compile farm servers are running debian etch (4.0) which
comes with autoconf 2.61 and no package for 2.59
According to Rask Ingemann Lambertsen autoconf 2.61
doesn't work correctly for GCC (see below).
What do GCC developpers do on debian etch?
Thanks in advance,
Laurent
On Fri, 2007-0
* Laurent GUERBY <[EMAIL PROTECTED]> [2007-07-03 12:45]:
> What do GCC developpers do on debian etch?
You should be able to install version 2.59 from snapshot.debian.net
(and then put in on hold so it won't get upgraded automatically).
--
Martin Michlmayr
http://www.cyrius.com/
On 7/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
> > I'm curious if it was the pre/fre changes. can you try -fno-tree-pre
> > and -fno-tree-fre and see if it slows down again?
> Adding -fno-tree-pre slows aermod back to
I'm seeing this failure with several recent revisions from the last day or
two:
...
checking whether the GNU Fortran compiler is working... no
configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/Develop/mainline-dn/build3/powerpc64-unknown-
"Alexander Monakov" <[EMAIL PROTECTED]> writes:
> The implementation follows the outline presented in my initial message
> on the project, here: http://gcc.gnu.org/ml/gcc/2007-03/msg00900.html
> . Data references and data dependency relations obtained via
> compute_dependencies_for_loop are copie
Uros Bizjak Mon, 02 Jul 2007 20:29:41 +0200 wrote:
Hello!
It is worth noticing that latest changes to gcc brought more than 75% speed-up
on Polyhedron aermod.f90 benchmark [1]. I can confirm this on 32bit nocona, and
double-checked on 64bit core2:
gcc -O3 -funroll-loops -ftree-vectorize -ffa
The target I am working on is 16-bit target and cannot support 64-
bit data types (DI mode).
How about conditionally declare the function?
#if LONG_LONG_TYPE_SIZE > 32
extern DItype __bswapdi2 (DItype);
#endif
So, I finally got around to this patch. While I was at it I went ahead
and check
Eric Christopher <[EMAIL PROTECTED]> writes:
> 2007-07-03 Eric Christopher <[EMAIL PROTECTED]>
>
> * libgcc2.h: Conditionally include __bswapsi2 and
> __bswapdi2.
This is OK if you change "include" to "declare" in the ChangeLog
entry.
Thanks.
Ian
* Laurent GUERBY wrote on Tue, Jul 03, 2007 at 12:45:45PM CEST:
>
> According to Rask Ingemann Lambertsen autoconf 2.61
> doesn't work correctly for GCC (see below).
[...]
> On Fri, 2007-06-29 at 11:27 +0200, Rask Ingemann Lambertsen wrote:
> > On Mon, Jun 25, 2007 at 08:11:31PM +0200, Laurent GUE
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Index: configure.ac
> ===
> --- configure.ac (revision 126245)
> +++ configure.ac (working copy)
> @@ -88,7 +88,8 @@
> # Export original configure arguments for use by sub-confi
On Tue, 2007-07-03 at 13:07 +0200, Richard Guenther wrote:
> On 7/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > > Daniel Berlin wrote:
> > > > I'm curious if it was the pre/fre changes. can you try -fno-tree-pre
> > > > and -fno-tree-fre a
* Andreas Schwab wrote on Tue, Jul 03, 2007 at 06:58:56PM CEST:
> To avoid expanding $progname twice:
>
> eval "set x \"\$progname\" $ac_configure_args"
Indeed; thanks! Updated proposed patch (I have no maintainer privs).
:ADDPATCH configure:
ChangeLog:
2007-07-03 Ralf Wildenhues <[EMAIL PRO
Is there a command option (for GCC, G++, and/or GAS) that will force
.rodata (like jump tables) to be located in the .data section?
Thanks,
Rich
Rich Tuttle
Ulticom, Inc.
(856)787-2745
[EMAIL PROTECTED]
"Richmond Tuttle" <[EMAIL PROTECTED]> writes:
> Is there a command option (for GCC, G++, and/or GAS) that will force
> .rodata (like jump tables) to be located in the .data section?
You can use a linker script to override the default placement.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PRO
On 7/3/07, Jeffrey Law <[EMAIL PROTECTED]> wrote:
On Tue, 2007-07-03 at 13:07 +0200, Richard Guenther wrote:
> On 7/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > > Daniel Berlin wrote:
> > > > I'm curious if it was the pre/fre changes. c
On Tue, Jul 03, 2007 at 08:50:29PM +0200, Andreas Schwab wrote:
> "H.J. Lu" <[EMAIL PROTECTED]> writes:
>
> > Where is it documented.
>
> Nowhere.
>
> > Gcc 4.3 just passes "-shared -pie" to linker. I don't see gcc driver
> > remove -pie.
>
> Look at the use of Scrt1.o. It's much of a mess.
>
On Tue, 3 Jul 2007, Vincent Lefevre wrote:
> The release of MPFR 2.3.0 is imminent. Please help to make this
> release as good as possible by downloading and testing this
> release candidate:
>
> http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.bz2
> http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.
On Tuesday 03 July 2007, Andreas Schwab wrote:
> "Richmond Tuttle" <[EMAIL PROTECTED]> writes:
> > Is there a command option (for GCC, G++, and/or GAS) that will force
> > .rodata (like jump tables) to be located in the .data section?
>
> You can use a linker script to override the default placemen
On 03 July 2007 22:14, Kenneth Zadeck wrote:
> David Edelsohn points out that some of the expanders could have all of
> this code removed since expanders only run before reload. I do not know
> how to figure this out.
I thought that movMM expanders could still be run /during/ reload, at the
ver
> I thought that movMM expanders could still be run /during/ reload, at the
> very least? Or does "some of the expanders" mean "excluding movMM" in
> particular? (I'm not sure if I should infer the word "those" between
> "removed since" and "expanders only").
Certainly movMM can run during re
Ollie Wild wrote:
As an aside to the ongoing git repository discussion, I'm curious if
anyone has experimented with committing changes to the GCC repository
via git-svn's dcommit command. I'm curious to know if it plays nicely
with GCC's svn commit machinery.
It should. git-svn is bidirection
Geoffrey Keating wrote:
> GCC's concept of visibility is very different to that of some other
> compilers.
Yes, and that may be a problem. For some features, we want to have GNU
semantics that are consistent that across platforms; for others, we want
to match other compilers on a particular plat
On 03/07/2007, at 5:13 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
GCC's concept of visibility is very different to that of some other
compilers.
Yes, and that may be a problem. For some features, we want to have
GNU
semantics that are consistent that across platforms; for others, w
Dave Korn wrote:
> On 03 July 2007 22:14, Kenneth Zadeck wrote:
>
>
>> David Edelsohn points out that some of the expanders could have all of
>> this code removed since expanders only run before reload. I do not know
>> how to figure this out.
>>
>
> I thought that movMM expanders could s
Geoffrey Keating wrote:
> Yes. __attribute__((visibility)) has consistent GNU semantics, and
> other features (eg. -fvisibility-ms-compat, __dllspec) match other
> compilers.
The only semantics that make sense on SymbianOS are the ones that allow
default visibility within a hidden class. So, wh
On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
Yes. __attribute__((visibility)) has consistent GNU semantics, and
other features (eg. -fvisibility-ms-compat, __dllspec) match other
compilers.
The only semantics that make sense on SymbianOS are the ones that
allow
Summary
---
The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. I plan
to make this release unless I am made aware of P1 regressions relative
to GCC 4.2.0.
At present, there are 29 P1s open against GCC 4.2.x, virtually all of
which are also present in GCC 4.3. Thus, you can kill
Geoffrey Keating wrote:
> On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
>
>> Geoffrey Keating wrote:
>>
>>> Yes. __attribute__((visibility)) has consistent GNU semantics, and
>>> other features (eg. -fvisibility-ms-compat, __dllspec) match other
>>> compilers.
>>
>> The only semantics that make
30 matches
Mail list logo
