Re: incomplete type return types
Mark Mitchell <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | | > The resason here is that, after we complained that A is incomplete | > (therefore cannot be used as return type in the function definition), | > cp/decl.c:check_function_type() changes the return type to void, thus | > giving misleading diagnostic later. | | That's the bug. It should change the return type to error_mark_node, | and then the code that check returns should be silent in that case. It turns out that start_preparsed_function() is a one-way drive-thru, i.e., there is no early exit and it does not check for whatever check_function_type() did. Setting the return type to error_mark_node makes the compiler die later in build_function_type -- which is unprepared to have error_mark_node as inputs. Would prefer to have build_function_type() also modified to be nice to error_mark_node? -- Gaby
SVN Problem?
I just tried to check in a change on the 4.1 branch. I get this nice little message : svn: Commit failed (details follow): svn: Authorization failed svn: Your commit message was left in a temporary file: svn:'/fuel98/export/svn/gcc-4_1-branch/svn-commit.2.tmp' Suggestions? jeff
Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1
On Tue, Nov 29, 2005 at 10:01:25PM +, Joern RENNECKE wrote:
> >If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT)
> >here, I'm afraid that would be much bigger ABI incompatibility.
> >Currently, say
> >typedef char __attribute__((vector_size (64))) v64qi;
> >is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is much
> >smaller.
> >GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
> >to their size, just vector_size 16 and 32 has been 8 bytes aligned
> >(BIGGEST_ALIGNMENT).
> >
> >
> That sounds very strange. Is there a rationale for that, or is this a
> SNAFU?
It is just a side-effect of the 3.4/4.0 code - if there was a supported
integer mode on the target for the requested size, then alignment of that
mode was used (and mode alignments are at most BIGGEST_ALIGNMENT).
If no integer mode was supported for that size, it would use the earlier
alignment, i.e. vector_size.
Unfortunately, while say vector_size (64) etc. vectors are IMHO very unlikely,
vector_size (16) will occurr in user programs from time to time and thus the
ABI incompatibility might affect existing programs.
We can document the incompatibility as a feature (after all, getting
rid of that alignment anomaly on s390{,x} wouldn't be a bad thing I guess).
>
> >Not capping to BIGGEST_ALIGNMENT might have issues with some object formats
> >though, if they don't support ridiculously big aligments.
> We have MAX_OFILE_ALIGNMENT for that.
But is it used for vector type alignments?
Jakub
Re: SVN Problem?
Jeffrey A Law wrote:
I just tried to check in a change on the 4.1 branch. I get this
nice little message :
svn: Commit failed (details follow):
svn: Authorization failed
svn: Your commit message was left in a temporary file:
svn:'/fuel98/export/svn/gcc-4_1-branch/svn-commit.2.tmp'
You probably are on a svn:// tree. Try something along the lines of
svn switch --relocate {svn://,svn+ssh://[EMAIL PROTECTED]/svn/gcc
Paolo
Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1
Jakub Jelinek wrote:
On Tue, Nov 29, 2005 at 10:01:25PM +, Joern RENNECKE wrote:
If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT)
here, I'm afraid that would be much bigger ABI incompatibility.
Currently, say
typedef char __attribute__((vector_size (64))) v64qi;
is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is much
smaller.
GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
to their size, just vector_size 16 and 32 has been 8 bytes aligned
(BIGGEST_ALIGNMENT).
That sounds very strange. Is there a rationale for that, or is this a
SNAFU?
It is just a side-effect of the 3.4/4.0 code - if there was a supported
integer mode on the target for the requested size, then alignment of that
mode was used (and mode alignments are at most BIGGEST_ALIGNMENT).
If no integer mode was supported for that size, it would use the earlier
alignment, i.e. vector_size.
I would call that a bug then.
Unfortunately, while say vector_size (64) etc. vectors are IMHO very unlikely,
vector_size (16) will occurr in user programs from time to time and thus the
ABI incompatibility might affect existing programs.
We can document the incompatibility as a feature (after all, getting
rid of that alignment anomaly on s390{,x} wouldn't be a bad thing I guess).
Having types with an alignment larger than BIGGEST_ALIGNMENT in the
absence of
alignment attributes is also an anomaly. And as you said, having
vectors larger than
BIGGEST_ALIGNMENT is not as likely as having ones that are within this
size, so making
the change to layout_struct to honour BIGGEST_ALIGNMENT for vectors
should not cause
worse incompatibilities than doing nothing.
Now that the vector types are still rather new, we still have a
reasonable chance to get this right
without causing too much disruption. Fixing this at a later date will
only get harder and harder.
Having excessive alignments for vector types would not only vaste space
on the stack and in structures,
but also requires run-time stack aligning code and extra overhead in
auto-vectorized code,
and is also likely to cause failure to use vector operations at all at
runtime because the alignment
constraints are not met.
Not capping to BIGGEST_ALIGNMENT might have issues with some object formats
though, if they don't support ridiculously big aligments.
We have MAX_OFILE_ALIGNMENT for that.
But is it used for vector type alignments?
It is not used for type alignments, but for variables. Thus, structs
that contains such vectors
still can have excessive alignment padding, but as a whole their
alignment is restricted to
MAX_OFILE_ALIGNMENT.
Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1
GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
to their size, just vector_size 16 and 32 has been 8 bytes aligned
(BIGGEST_ALIGNMENT).
It is just a side-effect of the 3.4/4.0 code - if there was a supported
integer mode on the target for the requested size, then alignment of that
mode was used (and mode alignments are at most BIGGEST_ALIGNMENT).
If no integer mode was supported for that size, it would use the earlier
alignment, i.e. vector_size. [...]
We can document the incompatibility as a feature (after all, getting
rid of that alignment anomaly on s390{,x} wouldn't be a bad thing I guess).
Capping the alignment of any vector type above vector_size(4) to 8 bytes
could also be an idea.
Paolo
Re: SVN Problem?
On Wed, 2005-11-30 at 02:01 -0700, Jeffrey A Law wrote: > I just tried to check in a change on the 4.1 branch. I get this > nice little message : > > svn: Commit failed (details follow): > svn: Authorization failed > svn: Your commit message was left in a temporary file: > svn:'/fuel98/export/svn/gcc-4_1-branch/svn-commit.2.tmp' > > > Suggestions? Did you check this out with svn://, instead of svn+ssh://? > jeff >
pr14516 and GCC 3.4
Hello! This PR is about missing USER_LABEL_PREFIX for static variables. The issue was fixed for 4.0, but for 3.4 there won't be a fix as stated in the audit trail by Mark Mitchell in comment #15. He probably based his decision on comment #14, where Geoff Keating states that this bug does only affect debugging programs that don't have full debugging info. That conclusion is wrong, the bug has a much more severe impact! A missing USER_LABEL_PREFIX can led to assembler errors if the variable name matches the name of a machine register if registers are used without a prefix and thats the default for a.out systems. This bug prevents using GCC 3.4 on targets with a nonzero USER_LABEL_PREFIX safely. Since 3.4 is the last 3.x version it should be usable on such system safely. A proposed patch in comment #7 was rejected in comment #8 without giving any details what problems the patch might cause. Can this bug get fixed with minimal efforts? Gunther
Suggestion
Hello! Maybe you got this type of mails, but maybe not. So i send it. :) Could you put an option into the compiler, to produce other error / warning outputs? The "file.c:line: error message" format is ok, but the stupid visual studio (which i use (good editor)) knows only the "file.c(line): error message" format. So it would be great, if i can switch to it. Or these messages should going (by an option) to the stdout rather than stderr, so i can write a parser (gcc a.c | myparser) to convert the messages. Please, forgive me, if this mail was annoying, but i think it would be a nice option. Thanks, and keep up the good work! Bye! János Szuromi Hungary
Re: Suggestion
YaniMan wrote: Hello! Maybe you got this type of mails, but maybe not. So i send it. :) Could you put an option into the compiler, to produce other error / warning outputs? The "file.c:line: error message" format is ok, but the stupid visual studio (which i use (good editor)) knows only the "file.c(line): error message" format. So it would be great, if i can switch to it. Or these messages should going (by an option) to the stdout rather than stderr, so i can write a parser (gcc a.c | myparser) to convert the messages. Please, forgive me, if this mail was annoying, but i think it would be a nice option. Why don't you try implementing this possibility yourself, it sounds like a quite manageable kind of project.
Re: Suggestion
"YaniMan" <[EMAIL PROTECTED]> wrote: > Or these messages should going (by an option) to the stdout rather than > stderr, so i can write a parser (gcc a.c | myparser) to convert the > messages. gcc a.c 2>&1 | myparser >&2 paul
Re: SVN conversion glitch?
On Wed, Nov 23, 2005 at 03:32:57PM +0100, Jakub Jelinek wrote: > While doing svn diff, I've noticed > gcc/config/i386/xm-dgux.h > gcc/config/i386/xm-sysv3.h > gcc/config/i386/xm-sun.h > gcc/config/i386/scodbx.h > files popped out of nowhere on the trunk (and through 4.1 branching > also on gcc-4_1-branch). There seem to be more conversion glichtes. I retrieved gcc-2_95-branch from the svn repository and diffed it with my CVS checkout. The diff contained lots of differences. Many files had different CVS $Id strings. I was told that this is harmless but what is the reason for this difference? However, there were a few files with different contents: diff -x .svn -x CVS -rup ../GCC2/config/mpw/ChangeLog GCC2/config/mpw/ChangeLog diff -x .svn -x CVS -rup ../GCC2/libio/fstream.h GCC2/libio/fstream.h diff -x .svn -x CVS -rup ../GCC2/libio/isgetsb.cc GCC2/libio/isgetsb.cc diff -x .svn -x CVS -rup ../GCC2/libio/isscan.cc GCC2/libio/isscan.cc diff -x .svn -x CVS -rup ../GCC2/libio/parsestream.h GCC2/libio/parsestream.h diff -x .svn -x CVS -rup ../GCC2/libio/stdstreams.cc GCC2/libio/stdstreams.cc diff -x .svn -x CVS -rup ../GCC2/libio/stream.h GCC2/libio/stream.h diff -x .svn -x CVS -rup ../GCC2/libio/strstream.h GCC2/libio/strstream.h Does that indicate a major problem for the svn repository for that branch? Thank you, Gunther Nikl
Re: SVN conversion glitch?
On Wed, 2005-11-30 at 16:49 +0100, Gunther Nikl wrote: > On Wed, Nov 23, 2005 at 03:32:57PM +0100, Jakub Jelinek wrote: > > While doing svn diff, I've noticed > > gcc/config/i386/xm-dgux.h > > gcc/config/i386/xm-sysv3.h > > gcc/config/i386/xm-sun.h > > gcc/config/i386/scodbx.h > > files popped out of nowhere on the trunk (and through 4.1 branching > > also on gcc-4_1-branch). > > There seem to be more conversion glichtes. I'm sure there are. It's a large repository, with 16 years of history, that has revisions generated by buggy CVS's, in addition to having a changeset grouping heuristic applied to it. > I retrieved gcc-2_95-branch > from the svn repository and diffed it with my CVS checkout. The diff > contained lots of differences. > Many files had different CVS $Id strings. I was told that this is harmless > but what is the reason for this difference? Because i didn't convert with cvs keyword substution on. > However, there were a few files with different contents: > > diff -x .svn -x CVS -rup ../GCC2/config/mpw/ChangeLog > GCC2/config/mpw/ChangeLog > diff -x .svn -x CVS -rup ../GCC2/libio/fstream.h GCC2/libio/fstream.h > diff -x .svn -x CVS -rup ../GCC2/libio/isgetsb.cc GCC2/libio/isgetsb.cc > diff -x .svn -x CVS -rup ../GCC2/libio/isscan.cc GCC2/libio/isscan.cc > diff -x .svn -x CVS -rup ../GCC2/libio/parsestream.h > GCC2/libio/parsestream.h > diff -x .svn -x CVS -rup ../GCC2/libio/stdstreams.cc > GCC2/libio/stdstreams.cc > diff -x .svn -x CVS -rup ../GCC2/libio/stream.h GCC2/libio/stream.h > diff -x .svn -x CVS -rup ../GCC2/libio/strstream.h GCC2/libio/strstream.h > > Does that indicate a major problem for the svn repository for that branch? Not necessarily. The conversion is not perfect. It can't be, because we are trying to recreate information we do not have. It is a heuristic to try to turn cvs commits into changesets. Sometimes it will pull something a little too much forward or backwards, because it happens to fall within the right group. There is no perfection here, sorry. --Dan
Re: SVN conversion glitch?
On Wed, Nov 30, 2005 at 10:57:42AM -0500, Daniel Berlin wrote: > On Wed, 2005-11-30 at 16:49 +0100, Gunther Nikl wrote: > > I retrieved gcc-2_95-branch from the svn repository and diffed it with > > my CVS checkout. The diff contained lots of differences. > > Many files had different CVS $Id strings. I was told that this is harmless > > but what is the reason for this difference? > > Because i didn't convert with cvs keyword substution on. Ok, then its indeed harmless. > > However, there were a few files with different contents: > > > > diff -x .svn -x CVS -rup ../GCC2/config/mpw/ChangeLog > > GCC2/config/mpw/ChangeLog > > diff -x .svn -x CVS -rup ../GCC2/libio/fstream.h GCC2/libio/fstream.h > > diff -x .svn -x CVS -rup ../GCC2/libio/isgetsb.cc GCC2/libio/isgetsb.cc > > diff -x .svn -x CVS -rup ../GCC2/libio/isscan.cc GCC2/libio/isscan.cc > > diff -x .svn -x CVS -rup ../GCC2/libio/parsestream.h > > GCC2/libio/parsestream.h > > diff -x .svn -x CVS -rup ../GCC2/libio/stdstreams.cc > > GCC2/libio/stdstreams.cc > > diff -x .svn -x CVS -rup ../GCC2/libio/stream.h GCC2/libio/stream.h > > diff -x .svn -x CVS -rup ../GCC2/libio/strstream.h GCC2/libio/strstream.h > > > > Does that indicate a major problem for the svn repository for that branch? > > Not necessarily. > > The conversion is not perfect. It can't be, because we are trying to > recreate information we do not have. > > It is a heuristic to try to turn cvs commits into changesets. Sometimes > it will pull something a little too much forward or backwards, because > it happens to fall within the right group. Maybe I should add that I didn't retrieve the "latest" state but a specific date. The only change to that branch after that date bumping gcc/version.c. The differences in the above mentioned files are probably harmless (a ChangeLog and libio). > There is no perfection here, sorry. I didn't want to imply that. My mail was intended as in information and to take actions if required. Gunther
Re: Suggestion
[EMAIL PROTECTED] said: > Or these messages should going (by an option) to the stdout rather than > stderr, so i can write a parser (gcc a.c | myparser) to convert the > messages. Ah, but that option does exist already: gcc a.c 2>&1 | myparser :-) Christian
RE: Suggestion
YaniMan wrote:
> Hello!
>
> Maybe you got this type of mails, but maybe not. So i send it. :)
Hey! Maybe you got this type of replies, but maybe not. So I send it too!
:)
> Could you put an option into the compiler, to produce other error /
> warning outputs?
> The "file.c:line: error message" format is ok, but the stupid visual
> studio (which i use (good editor)) knows only the "file.c(line): error
> message" format. So it would be great, if i can switch to it.
You should be able to make it work something like this:
Index: gcc-3.3.3/gcc/cpperror.c
===
RCS file: /cvsroot/dlxtools/gcc-3.3.3/gcc/cpperror.c,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 cpperror.c
--- gcc-3.3.3/gcc/cpperror.c26 Mar 2004 13:22:22 - 1.1.1.1
+++ gcc-3.3.3/gcc/cpperror.c30 Nov 2005 16:39:13 -
@@ -56,9 +56,9 @@ print_location (pfile, line, col)
if (line == 0)
fprintf (stderr, "%s:", map->to_file);
else if (CPP_OPTION (pfile, show_column) == 0)
- fprintf (stderr, "%s:%u:", map->to_file, line);
+ fprintf (stderr, "%s(%u)", map->to_file, line);
else
- fprintf (stderr, "%s:%u:%u:", map->to_file, line, col);
+ fprintf (stderr, "%s(%u):%u:", map->to_file, line, col);
fputc (' ', stderr);
}
Index: gcc-3.3.3/gcc/diagnostic.c
===
RCS file: /cvsroot/dlxtools/gcc-3.3.3/gcc/diagnostic.c,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 diagnostic.c
--- gcc-3.3.3/gcc/diagnostic.c 26 Mar 2004 13:22:22 - 1.1.1.1
+++ gcc-3.3.3/gcc/diagnostic.c 30 Nov 2005 16:39:13 -
@@ -855,7 +855,7 @@ diagnostic_build_prefix (diagnostic)
abort();
return diagnostic->location.file
-? build_message_string ("%s:%d: %s",
+? build_message_string ("%s(%d) %s",
diagnostic->location.file,
diagnostic->location.line,
_(diagnostic_kind_text[diagnostic->kind]))
That'll get 99% of the error/warning messages you're worried about.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: SVN Problem?
On Wed, 2005-11-30 at 13:44 +0100, Paolo Bonzini wrote:
> You probably are on a svn:// tree. Try something along the lines of
Ahhh.
> svn switch --relocate {svn://,svn+ssh://[EMAIL PROTECTED]/svn/gcc
Thanks. I doubt I would have come up with that one on my own! :-)
jeff
Re: pr14516 and GCC 3.4
Gunther Nikl <[EMAIL PROTECTED]> writes: > This PR is about missing USER_LABEL_PREFIX for static variables. The issue > was fixed for 4.0, but for 3.4 there won't be a fix as stated in the audit > trail by Mark Mitchell in comment #15. He probably based his decision on > comment #14, where Geoff Keating states that this bug does only affect > debugging programs that don't have full debugging info. That conclusion is > wrong, the bug has a much more severe impact! A missing USER_LABEL_PREFIX > can led to assembler errors if the variable name matches the name of > a machine register if registers are used without a prefix and thats the > default for a.out systems. This bug prevents using GCC 3.4 on targets > with a nonzero USER_LABEL_PREFIX safely. Since 3.4 is the last 3.x > version it should be usable on such system safely. > > A proposed patch in comment #7 was rejected in comment #8 without giving > any details what problems the patch might cause. Can this bug get fixed > with minimal efforts? There are more details about this here: http://sourceware.org/ml/binutils/2005-11/msg00385.html Basically, for an m68k-aout target, gcc 3.4 apparently does not emit a leading underscore for static variables. Ian
Re: incomplete type return types
Gabriel Dos Reis wrote: Would prefer to have build_function_type() also modified to be nice to error_mark_node? Yes, I see no reason for it not to. Jason
Re: Torbjorn's ieeelib.c
On Tue, Nov 29, 2005 at 10:58:32PM +, Joseph S. Myers wrote: > (Incidentally, why does libgcc-std.ver not include __unordxf2 and > __unordtf2 although it has __unordsf2 and __unorddf2?) I'm sure it wasn't intentional. r~
Adding new target OS for GCC
Hi, What is the prefered way to add a new target OS for GCC? I've added the support to an older version of GCC (2.95) but don't want to redo the work as GCC evolves. Regards, Leif Ekblad www.rdos.net/rdos
Re: pr14516 and GCC 3.4
Gunther Nikl wrote: > Hello! > > This PR is about missing USER_LABEL_PREFIX for static variables. The issue > was fixed for 4.0, but for 3.4 there won't be a fix as stated in the audit > trail by Mark Mitchell in comment #15. He probably based his decision on > comment #14, where Geoff Keating states that this bug does only affect > debugging programs that don't have full debugging info. That conclusion is > wrong, the bug has a much more severe impact! Yes, it's true that this is why I thought it was not important enough to fix in GCC 3.4.x. However, I am no longer managing releases from the 3.4.x branch, so it's up to Gaby to decide if he wants to reopen the issue. (I've cc'd Gaby on this message.) Geoff's patch in Comment #11 is clearly too big to backport to 3.4. Both Geoff and Ian are very knowledgeable, and I don't have personally have any opinion about whether or not the patch in comment #7 is correct or not, so I don't think I can say anything useful about whether or not that patch might be a good starting point. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Adding new target OS for GCC
> What is the prefered way to add a new target OS for GCC? I've added > the support to an older version of GCC (2.95) but don't want to redo > the work as GCC evolves. The best thing to do is to get the port up to scratch relative to the current mainline version and then contribute it to the GCC project. Once it is in the tree, it is more likely to be kept up to date with infrastructure changes (although someone will still be expected to actively maintain the port). Ben
Re: pr14516 and GCC 3.4
Mark Mitchell <[EMAIL PROTECTED]> writes: | Gunther Nikl wrote: | > Hello! | > | > This PR is about missing USER_LABEL_PREFIX for static variables. The issue | > was fixed for 4.0, but for 3.4 there won't be a fix as stated in the audit | > trail by Mark Mitchell in comment #15. He probably based his decision on | > comment #14, where Geoff Keating states that this bug does only affect | > debugging programs that don't have full debugging info. That conclusion is | > wrong, the bug has a much more severe impact! | | Yes, it's true that this is why I thought it was not important enough to | fix in GCC 3.4.x. | | However, I am no longer managing releases from the 3.4.x branch, so it's | up to Gaby to decide if he wants to reopen the issue. (I've cc'd Gaby | on this message.) | | Geoff's patch in Comment #11 is clearly too big to backport to 3.4. Agreed. | Both Geoff and Ian are very knowledgeable, and I don't have personally | have any opinion about whether or not the patch in comment #7 is correct | or not, so I don't think I can say anything useful about whether or not | that patch might be a good starting point. I'd defer to Geoff and Ian for the correctness issue. *If* there is an acceptable patch, it won't be for 3.4.5. -- Gaby
[C++] cp_token::type and cp_token::keyword
In cp/parser.c:cp_parser_declaration(), we have the following code
/* Try to figure out what kind of declaration is present. */
token1 = *cp_lexer_peek_token (parser->lexer);
if (token1.type != CPP_EOF)
token2 = *cp_lexer_peek_nth_token (parser->lexer, 2);
else
token2.type = token2.keyword = RID_MAX;
It looks to me like the last line is a typo for
{
token2.type = CPP_EOF;
token2.keyword = RID_MAX;
}
as cp_token::type and cp_token::keyword are of different types and we
don't seem to mix them except at that single place. Is that correct?
-- Gaby
PS: that was caught by a build of cp/parser.c with g++.
gcc help
Hi , I am new to gcc and shell commands. I am trying to compile my code using gcc 3.3.2 provided with AMD Au1550 development CD. When I compile my code, I get an error message with undefined references to printf and other file i/o functions. I saw a couple of emails in the forum with the same problem.But, I think I have problem with the makefile I am using. I never wrote a make file before and I am using the makefile from the hello World example given with Au1550 CD. It works for that example, but it crashes with my code. I am attching the makefile with this email.. # Program name NAME = test # Endian ifndef ENDIAN ENDIAN = EL endif # Tool-chain used for compilation of code # Win32 Cygwin toolchain TOOLCHAIN = cygwin # Monta Vista Hard Hat Linux toolchain #TOOLCHAIN = hhl ifeq ($(TOOLCHAIN),cygwin) TOOLSDIR = /usr/local/comp/mips-elf/gcc-3.3.2 AS = $(TOOLSDIR)/bin/mips-elf-as CC = $(TOOLSDIR)/bin/mips-elf-gcc -fno-builtin LD = $(TOOLSDIR)/bin/mips-elf-ld OD = $(TOOLSDIR)/bin/mips-elf-objdump OC = $(TOOLSDIR)/bin/mips-elf-objcopy #STRIP = $(TOOLSDIR)/bin/mips-elf-strip endif ifeq ($(TOOLCHAIN),hhl) TOOLSDIR = /opt/hardhat/devkit/mips/fp_le AS = $(TOOLSDIR)/bin/mips_fp_le-as CC = $(TOOLSDIR)/bin/mips_fp_le-gcc -fno-pic -mno-abicalls LD = $(TOOLSDIR)/bin/mips_fp_le-ld OD = $(TOOLSDIR)/bin/mips_fp_le-objdump OC = $(TOOLSDIR)/bin/mips_fp_le-objcopy #STRIP = $(TOOLSDIR)/bin/mips_fp_le-strip endif RM = rm -f # # GCC options valid for Au1000 # CFLAGS = -mips32 -G 0 -O2 -$(ENDIAN) -D$(ENDIAN) -Wa,-G0,-non_shared -I. # # Default rules for compiling/assembling # .c.o: $(CC) -c $(CFLAGS) $< -o $@ .S.o: $(CC) -c $(CFLAGS) -D_ASSEMBLER_ $< -o $@ # # Files to compile # OBJS = \ test.o # # Rule for making # all: $(OBJS) $(LD) -$(ENDIAN) -T test.ld -G 0 $(OBJS) -o $(NAME).elf $(OD) -D $(NAME).elf > $(NAME).dis $(OC) -O srec $(NAME).elf $(NAME).rec clean: $(RM) *.o $(RM) *.dis $(RM) *.rec $(RM) *.elf $(RM) *~ I got the linnker directive from the hello world example.I assume the problem is with the linker and with the test.ld file from the hello world example. I used SDE toolchain before with the same code ,but a different make file but I never got this problem before. I really need help on this immediately. Thanks in advance - Pati -- Sent from the gcc - General forum at Nabble.com: http://www.nabble.com/gcc-help-t648991.html#a1725379
Re: SVN conversion glitch?
On Nov 30, 2005, at 7:49 AM, Gunther Nikl wrote: There seem to be more conversion glichtes. I retrieved gcc-2_95-branch from the svn repository and diffed it with my CVS checkout. The diff contained lots of differences. Many files had different CVS $Id strings. I was told that this is harmless but what is the reason for this difference? Some (all?) of these were probably caused by changing the cvs repo pre-svn switchover. In cvs these things are not version controlled, and `fixing' them caused newly fetched files to then be different then those same exact files fetched in the past (before they were `fixed') even thoughy one fetches the same exact version. The only solution is to never check in a file without -ko in cvs in the first place. svn improves upon this by having substitutions all off in the first place. You can see if this is the case by refetching from cvs and then comparing to svn.
Re: SVN conversion glitch?
On Wed, 2005-11-30 at 14:53 -0800, Mike Stump wrote: > On Nov 30, 2005, at 7:49 AM, Gunther Nikl wrote: > > There seem to be more conversion glichtes. I retrieved gcc-2_95-branch > > from the svn repository and diffed it with my CVS checkout. The diff > > contained lots of differences. > > Many files had different CVS $Id strings. > > > I was told that this is harmless but what is the reason for this > > difference? > > Some (all?) of these were probably caused by changing the cvs repo > pre-svn switchover. In cvs these things are not version controlled, > and `fixing' them caused newly fetched files to then be different > then those same exact files fetched in the past (before they were > `fixed') even thoughy one fetches the same exact version. The only > solution is to never check in a file without -ko in cvs in the first > place. svn improves upon this by having substitutions all off in the > first place. > > You can see if this is the case by refetching from cvs and then > comparing to svn. Well, he was fetching by date, which makes it worse, since as i said, commit grouping will cause revision by date to not match up with CVS. tags, etc (IE things with very explicit versions of all the files involved) should match up.
Re: gcc help
On Nov 30, 2005, at 2:40 PM, pati (sent by Nabble.com) wrote: I am trying to compile my code using gcc 3.3.2 provided with AMD Au1550 development CD. Wrong forum for this question. $(LD) -$(ENDIAN) -T test.ld -G 0 $(OBJS) -o $(NAME).elf Don't use ld to link, use gcc to link.
new c++ restrictions?
For the last few months, gcc 4.1 has had problems compling
the following code in posRMSDPot.cc in xplor-nih...
IStringStream iNoComments( stripped );
// read NOEPot table
CDSStringStreamBuf dum;
while ( !iNoComments.eof() && !iNoComments.fail() ) {
String word; iNoComments >> word;
if ( word.glob("assi*",1) ) {
PosRMSDPot_Restraint* restraint = new PosRMSDPot_Restraint(this);
iNoComments >> *restraint;
if ( restraint->ok() ) {
restraints_.append( restraint );
if (verbose())
cout << "PosRMSDPot::addRestraints: added restraint: "
<< *restraint << '\n';
} else {
cout << "PosRMSDPot::addRestraints: error adding restraint.\n";
delete restraint;
which generates an error...
posRMSDPot.cc: In member function 'void PosRMSDPot::addRestraints(const
String&)':
posRMSDPot.cc:145: error: no match for 'operator>>' in 'iNoComments >> *
restraint'
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.1.0/../../../../include/c++/4.1.0/istream:131:
note: candidates are: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(std::basic_istream<_CharT,
_Traits>& (*)(std::basic_istream<_CharT, _Traits>&)) [with _CharT = char,
_Traits = std::char_traits]
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.1.0/../../../../include/c++/4.1.0/istream:134:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(std::basic_ios<_CharT,
_Traits>& (*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits =
std::char_traits]
etc...
which is the line "iNoComments >> *restraint;". There also is a compile error
at...
posRMSDPot.cc:150: error: no match for 'operator<<' in 'std::operator<< [with
_Traits = std::char_traits](((std::basic_ostream >&)(& std::cout)), ((const
char*)"PosRMSDPot::addRestraints: added restraint: ")) << * restraint'
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.1.0/../../../../include/c++/4.1.0/bits/ostream.tcc:67:
note: candidates are: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT,
_Traits>& (*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char,
_Traits = std::char_traits]
which is the line " << *restraint << '\n';". Any ideas why this breakage has
occured and what the proper workaround is? GCC 4.0.2 doesn't have a problem
with this source as did GCC 4.1 until a few months back.
Jack
Help required - ICE in GCC for my target
Hi all
I am porting GCC compiler to new 16 bit target. I am using GCC-4.0.x
For one of the target specific options, I am using PSI mode for
representing pointers.
If I compile the following test code with this target specific option
along with any of the optimization options I am getting an ICE.
Command line is
>>> target-elf-gcc -mlarge -O2 ICE.c -c
=
volatile double gd[32];
int main ()
{
int i;
int j;
for (i = 0; i < 32; i++)
if (gd[i] != i * 4 )/* In this statement If I use loop
invariant instead of 'i' in LHS or RHS of comparison program is getting
compiled */
abort ();
exit (0);
}
=
ICE I am getting is :
internal compiler error: in emit_move_insn, at expr.c:3079
I tried to debug the code and I observed that it occurs in the function
emit move instruction Emit_move_instruction(rtx X,rtx Y).
Modes of X an Y are PSI and SI respectively and because of that it is
failing.
I have also provided RTL's for "extendpsisi" and "truncsipsi" (for
converting between PSI and SI modes).
I also tried to take RTL dump , but didn't get any dump , it is failing
before generating RTL's.
Any pointers/help/direction in regard would be nice.
Is there any target specific stuff I will have to look into?
Thanking in advance
Regards,
Shrirang P Khisti
KPIT Cummins Infosystems Ltd
Re: Help required - ICE in GCC for my target
> I have also provided RTL's for "extendpsisi" and "truncsipsi" (for > converting between PSI and SI modes). You need extendpsisi2, truncsipsi2, and zero_extendpsisi2. The m32c port uses PSI for pointers also; you can use it as an example.
