David Fernandez kirjoitti:
Hi there,
I don't know if this is the right place for questions about the gcc
build/install process. Let me know the right place otherwise.
I'm trying to compile a cross-compiler from gcc-4.0.2 sources.
It is configured this way:
/usr
Hi,
I have successfully installed gcc-3.4.5 on DS10 Alpha server.
- Output from config.guess: alphaev6-dec-osf4.0g
- Output of gcc -v:
Reading specs from /usr/local/lib/gcc/alphaev6-dec-osf4.0g/3.4.5/specs
Configured with: /home/yok001/temp/packages/gcc-3.4.5/configure
Thread model: posix
On Thu, Feb 16, 2006 at 03:46:57PM -0800, James E Wilson wrote:
> On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> > I took the liberty to fix the format issue on behalf of Denis. Is this
> > OK for mainline?
>
> Yes, this looks good to me.
I checked it in. Here is the testcase.
H.J.
2006-02
On Thu, 16 Feb 2006, Sylvain Munaut wrote:
> Move/Load/Store without flag is no problem. But for add, to allow
> multiword add, carry is needed and I can't make it optionnal.
As I hinted, perhaps you can have the multiword carry a separate
one from the flags carry, perhaps moved over with a separa
Denis Chertykov <[EMAIL PROTECTED]> writes:
> > > I think that better to call update_eliminables() somewhere after
> > > setup_save_areas()
> >
> > Exactly. We do that. About 15 lines after the lines you quoted
> > above.
> >
> > What am I missing?
>
> I'm (exactly AVR port) need in call to u
On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> I took the liberty to fix the format issue on behalf of Denis. Is this
> OK for mainline?
Yes, this looks good to me.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Thu, Feb 16, 2006 at 12:34:19PM -0800, James E Wilson wrote:
> On Thu, 2006-02-16 at 11:59, Denis Nagorny wrote:
> > It's corrected and tested on ia64 and x86-64. I've attached new version.
> > Denis.
>
> This look pretty good. There is still one place where the spacing looks
> funny.
>
> > +
Snapshot gcc-4.0-20060216 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060216/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> cc1: error: unrecognized command line option "-f "
I don't see any such option in the last xgcc command. What's your
gmake version? I've seen problems using versions earlier than 3.80.
The next most likely possibility is that this is another loop
invariant bug: http://gcc.gnu.org/ml/gcc-patch
Hi,
I am building m68k-rtems (m68k-elf) right now
on the head and seeing a cc1 which has been running
17:37.05 according to top on a fast machine running
Fedora Core 3. It is a AMD Athlon(tm) 64 X2 Dual Core
Processor 3800+ at 2Ghz.
The last thing I see in the build log is this:
-c ../../gcc/gc
Hans-Peter Nilsson wrote:
> On Wed, 15 Feb 2006, DJ Delorie wrote:
> I wrote:
>
>>>Anyway, at least keep a way to add reg+reg and reg+integer, load and
>>>store of memory and load of integer and address without condition
>>>code effects and your port has a chance to avoid the related bloat.
>>
>
On Thu, 2006-02-16 at 11:59, Denis Nagorny wrote:
> It's corrected and tested on ia64 and x86-64. I've attached new version.
> Denis.
This look pretty good. There is still one place where the spacing looks
funny.
> + if (test >= regno && test < endregno)
> + return 1;
Check
Andrew Pinski wrote:
and was said to involve undefined behavior. "However, there is
nothing to
suggest that a not-strictly-conforming array type can magically be
transformed into a strictly conforming pointer parameter via this rule."
Ok, I get it. The 'incomplete type' phrase refers to arra
Andrew Pinski wrote:
On Feb 16, 2006, at 3:20 PM, H. J. Lu wrote:
Should
+static int reg_inc_found_and_valid_p (unsigned int, unsigned int, rtx);
be removed if we do this way?
Yes, in fact it does not need to be there in the first place as
the function is declared before the use.
-- Pin
Andrew Pinski wrote:
What about defining the code this way:
#ifdef AUTO_INC_DEC
+ static int
+ reg_inc_found_and_valid_p (unsigned int regno,
+unsigned int endregno,
+rtx insn)
+ {
...
}
#else
#define reg_inc_found_and_valid_p(regno,endre
On Feb 16, 2006, at 3:20 PM, H. J. Lu wrote:
Should
+static int reg_inc_found_and_valid_p (unsigned int, unsigned int,
rtx);
be removed if we do this way?
Yes, in fact it does not need to be there in the first place as
the function is declared before the use.
-- Pinski
On Thu, Feb 16, 2006 at 03:03:02PM -0500, Andrew Pinski wrote:
>
> On Feb 16, 2006, at 2:59 PM, Denis Nagorny wrote:
>
> >James E Wilson wrote:
> >>Yes, that is what I was suggesting.
> >
> >It's corrected and tested on ia64 and x86-64. I've attached new
> >version.
> >Denis.
> >+ /* Return 1 if
On Feb 16, 2006, at 2:59 PM, Denis Nagorny wrote:
James E Wilson wrote:
Yes, that is what I was suggesting.
It's corrected and tested on ia64 and x86-64. I've attached new
version.
Denis.
+ /* Return 1 if registers from REGNO to ENDREGNO are the subjects of a
+REG_INC note in insn INSN
James E Wilson wrote:
Yes, that is what I was suggesting.
It's corrected and tested on ia64 and x86-64. I've attached new version.
Denis.
Index: reload.c
===
*** reload.c(revision 35)
--- reload.c(working copy)
***
On Tue, Feb 14, 2006 at 06:08:42PM -0800, Mark Mitchell wrote:
> Aldy Hernandez wrote:
>
> > Do we keep a hash of functions that have been written out somewhere?
>
> Not to my knowledge.
>
> > I'd hate to walk the entire hash table each time we write out a function
> > searching for the types th
On Feb 16, 2006, at 2:32 PM, Andrew Pinski wrote:
Even more important:
http://gcc.gnu.org/ml/gcc/2005-02/msg00026.html
Which is the answer you are looking for:
But the constraint in C99 is on array declarators, "The element type
shall
not be an incomplete or function type.". This applies
On Feb 16, 2006, at 1:18 PM, Joern RENNECKE wrote:
The issue there is completely different. The array has definetly no
completed type.
In the testcase I have given - which is pruned down from the pthread.h
header file on a linux installation - after applying adjustment, you
get:
extern vo
On Feb 16, 2006, at 1:18 PM, Joern RENNECKE wrote:
Andrew Pinski wrote:
GCC before 4.0.0 was incorrect at not rejecting this code.
See PR 19333.
Use -pedantic with 3.2.3 and you will get a warning.
Yes, I do, but it is also questionable if this warning is required or
even useful.
Also
Andrew Pinski wrote:
GCC before 4.0.0 was incorrect at not rejecting this code.
See PR 19333.
Use -pedantic with 3.2.3 and you will get a warning.
Yes, I do, but it is also questionable if this warning is required or
even useful.
Also see:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00
On Feb 16, 2006, at 12:52 PM, Joern RENNECKE wrote:
The following code gives an error with gcc 4.1:
struct tag;
extern void f (struct tag a[1]);
gcc 3.2.3 compiles this code without complaint.
GCC before 4.0.0 was incorrect at not rejecting this code.
See PR 19333.
Use -pedantic with 3.2.3
The following code gives an error with gcc 4.1:
struct tag;
extern void f (struct tag a[1]);
gcc 3.2.3 compiles this code without complaint.
I'm not sure what the c99 standard is actually saying about this code.
On the one hand, in 6.7.5.2, it says about array declarators:
The element type shal
Ian Lance Taylor writes:
[...]
>
> > I think that better to call update_eliminables() somewhere after
> > setup_save_areas()
>
> Exactly. We do that. About 15 lines after the lines you quoted
> above.
>
> What am I missing?
I'm (exactly AVR port) need in call to update_eliminables() somew
On Thu, Feb 16, 2006 at 03:28:46PM +, Paul Brook wrote:
> > The point is that from a gfortran perspective -mlong-double-128 doesn't
> > change the ABI, it merely adds to it (which is sort of a change, but less
> > invasive than changing long double from 8bytes to 16bytes). So we can
> > easily
On Thursday 16 February 2006 15:18, Richard Guenther wrote:
> On 2/16/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> > On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote:
> > > Hi all,
> > >
> > > I'm sending this mail because I'm a bit confused about the
> > > -mlong-double-128 option
>
> On 2/16/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> > On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote:
> > > Hi all,
> > >
> > > I'm sending this mail because I'm a bit confused about the
> > > -mlong-double-128 option on (for example) ppc64-linux, and its impact
> > > on gfo
On 2/16/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote:
> > Hi all,
> >
> > I'm sending this mail because I'm a bit confused about the
> > -mlong-double-128 option on (for example) ppc64-linux, and its impact
> > on gfortran/libgfortran
On Thursday 16 February 2006 15:14, François-Xavier Coudert wrote:
> > Having gfortran magically know about certain ABI breaking options, and
> > doing funny things on certain targets seems a very bad precedent to me.
>
> Then, I think we should have the front-end refuse the option. It's
> annoying
On 2/16/06, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 16, 2006 at 01:57:39PM +0100, Fran?ois-Xavier Coudert wrote:
> > > I guess libgfortran has configury to figure out if kind=16 is available?
> >
> > Yes.
> >
> > > If so then libgfortran should be built with -mlong-double-128, as thi
> Having gfortran magically know about certain ABI breaking options, and doing
> funny things on certain targets seems a very bad precedent to me.
Then, I think we should have the front-end refuse the option. It's
annoying to have a compiler accept code, and only tell you at runtime
(at the end of
On Thursday 16 February 2006 11:09, François-Xavier Coudert wrote:
> Hi all,
>
> I'm sending this mail because I'm a bit confused about the
> -mlong-double-128 option on (for example) ppc64-linux, and its impact
> on gfortran/libgfortran.
>
> When I simply bootstrap a compiler with "configure
> --w
p -o ../../gnatchop --GCC="../../xgcc -B../../
- -static-libgcc -I../rts -I.
- -I/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/ada" ../../prefix.o
../../version.o targext.o link.o ../rts/libgnat.a
../../../libiberty/libiberty.a /usr/lib/libcl.a
GNATLINK 4.2.0 20060216 (expe
On Thu, Feb 16, 2006 at 01:57:39PM +0100, Fran?ois-Xavier Coudert wrote:
> > I guess libgfortran has configury to figure out if kind=16 is available?
>
> Yes.
>
> > If so then libgfortran should be built with -mlong-double-128, as this
> > should only add extra symbols that do not conflict with k
> cc1: error: ../include/sys/version.h: No such file or directory
>
> What I'm doing wrong?. Where should I get the missing header files?.
This is a header that comes with DJGPP's library. Like most cross
compilers, you have to install part of the runtime package (usually at
least the hea
> The patch proposed by Olivier applied to 4.1 gives 0 failures for the whole
> acats testsuite, as you can see:
>
> LAST_UPDATED:
> === acats tests ===
>
> === acats Summary ===
> # of expected passes 2316
> # of unexpected failures 0
While not quite as
> I guess libgfortran has configury to figure out if kind=16 is available?
Yes.
> If so then libgfortran should be built with -mlong-double-128, as this
> should only add extra symbols that do not conflict with kind=4 and kind=8
> ones.
Hum, that has to be done early in the configury (before all
On 2/16/06, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm sending this mail because I'm a bit confused about the
> -mlong-double-128 option on (for example) ppc64-linux, and its impact
> on gfortran/libgfortran.
>
> When I simply bootstrap a compiler with "configure
> --with-
As previously, announced the GCC 4.1 branch is now frozen. All
non-documentation changes now require my explicit approval.
I had hoped to generate a release candidate last night, but (a) there
are a couple of new PRs I need to review, and (b) I'm onsite with a
customer, and didn't hvae as much ti
On Wed, 15 Feb 2006, DJ Delorie wrote:
I wrote:
> > Anyway, at least keep a way to add reg+reg and reg+integer, load and
> > store of memory and load of integer and address without condition
> > code effects and your port has a chance to avoid the related bloat.
>
> At least, move/load/store shou
> I don't know if this is the right place for questions about
> the gcc build/install process. Let me know the right place
> otherwise.
It would be better to start on the gcc-help mailing list. Also,
consider looking into using crosstool to assist with building.
Ben
Hi there,
I don't know if this is the right place for questions about the gcc
build/install process. Let me know the right place otherwise.
I'm trying to compile a cross-compiler from gcc-4.0.2 sources.
It is configured this way:
/usr/src/redhat/BUILD/gcc-4.0.2/
Hi all,
I'm sending this mail because I'm a bit confused about the
-mlong-double-128 option on (for example) ppc64-linux, and its impact
on gfortran/libgfortran.
When I simply bootstrap a compiler with "configure
--with-cpu=default32", I get a gfortran that does only have kind=4 and
kind=8 reals
Eric Botcazou wrote:
I have read the gcc-summit 2005 publication from Eric Botcaczou, Cyrille
Comar and Oliver Hainque about static stack analysis.
This is a quite interresting approach, especially for embedded systems.
While reading the article i saw many talking about ada but not for C.
Is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Geert Bosch schrieb:
>
> On Feb 15, 2006, at 13:28, John David Anglin wrote:
>
>> Understood. My question was what should the define for
>> WIDEST_HARDWARE_FP_SIZE be when generating code for a target
>> with no hardware floating point support (e.g.
> I have read the gcc-summit 2005 publication from Eric Botcaczou, Cyrille
> Comar and Oliver Hainque about static stack analysis.
>
> This is a quite interresting approach, especially for embedded systems.
>
> While reading the article i saw many talking about ada but not for C.
>
> Is the patch o
Hi all.
I have read the gcc-summit 2005 publication from Eric Botcaczou, Cyrille
Comar and Oliver Hainque about static stack analysis.
This is a quite interresting approach, especially for embedded systems.
While reading the article i saw many talking about ada but not for C.
Is the patch
50 matches
Mail list logo
