bugzilla broken?
Hi, for reasons I don't know, I am not able to create attachments in gcc's bugzilla for ca the last 24hrs. When doing so, I am greeted with the message below. --- snip --- Internal Error GCC Bugzilla has suffered an internal error. Please save this page and send it to [EMAIL PROTECTED] with details of what you were doing at the time this message appeared. URL: http://gcc.gnu.org/bugzilla/attachment.cgi undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58 --- snip --- dberlin has been mailed, but no reaction so far. Ralf
RE: bugzilla broken?
On Thu, 2007-05-03 at 10:36 +0100, Dave Korn wrote: > On 03 May 2007 08:52, Ralf Corsepius wrote: > > > Hi, > > > > for reasons I don't know, I am not able to create attachments in gcc's > > bugzilla for ca the last 24hrs. When doing so, I am greeted with the > > message below. > > > > --- snip --- > > Internal Error > > > > GCC Bugzilla has suffered an internal error. Please save this page and > > send it to [EMAIL PROTECTED] with details of what you were doing at > > the time this message appeared. > > > > URL: http://gcc.gnu.org/bugzilla/attachment.cgi > > > > undef error - Undefined subroutine Fh::slice at > > data/template/template/en/default/global/hidden-fields.html.tmpl line > > 58 > > --- snip --- > > dberlin has been mailed, but no reaction so far. > > > Clear your cookie and try again. Thanks, this helped. Ralf
Re: bugzilla broken?
On Thu, 2007-05-03 at 07:01 -0400, Daniel Berlin wrote: > On 5/3/07, Ralf Corsepius <[EMAIL PROTECTED]> wrote: > > Hi, > > > > for reasons I don't know, I am not able to create attachments in gcc's > > bugzilla for ca the last 24hrs. When doing so, I am greeted with the > > message below. > > > > --- snip --- > > Internal Error > > > > GCC Bugzilla has suffered an internal error. Please save this page and > > send it to [EMAIL PROTECTED] with details of what you were doing at > > the time this message appeared. > > > > URL: http://gcc.gnu.org/bugzilla/attachment.cgi > > > > undef error - Undefined subroutine Fh::slice at > > data/template/template/en/default/global/hidden-fields.html.tmpl line > > 58 > > --- snip --- > > Sadly, I can't make a better error message here without a bunch of > supporting code that got later added in bugzilla. > > What is actually happening is that you aren't logged in when you try > to submit the attachment. What actually has happened is: 1. I submitted a PR, and was asked to login several times inbetween. 2. Later I returned to "PR XXX", pressed "Create attachment" and ... first was asked to login, then created the attachment. When having finished to fill out the form, I pressed "submit" ... and wasn't asked for a password, instead had been greeted with the error message. No obvious indication of a broken/outdated cookie, no indication of a missing log-in (I even requested a new password in-between ;) ) >> dberlin has been mailed, but no reaction so far. > >I was off fixing my Nintendo Wii, so i wasn't checking email :) Well, we all are AFK from time to time - That's why I gradually was increasing the "visibility" of complaining. Ralf
struct __attribute((packed));
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
struct entrystruct *e1 __attribute__ ((packed));
struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e2 to point to a
"packed struct entrystruct", but this doesn't seem to be what GCC
interprets this code.
Ralf
Re: struct __attribute((packed));
On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote:
> Ralf Corsepius wrote:
>
> >Hi,
> >
> >I just tripped over this snipped below in a piece of code, I didn't
> >write and which I don't understand:
> >
> >...
> >struct somestruct {
> > struct entrystruct *e1 __attribute__ ((packed));
> > struct entrystruct *e2 __attribute__ ((packed));
> >};
> >...
> >
> >Is this meaningful?
> >
> >I guess the author wanted e1 and e2 to point to a
> >"packed struct entrystruct", but this doesn't seem to be what GCC
> >interprets this code.
> >
> >
> >
> >
>
> Take a look at the manual in the section about attributes of variables,
> <http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Variable-Attributes.html#Variable-Attributes>
I read this, over and over again, before posting, but ...
> It seems that GCC will interpret the above as e1 and e2 is packed within
> the struct somestruct so that e2 "immediately follows e1" (according to
> the manual). The packed attribute in this case does not refer to what e1
> and e2 is pointing to.
That's what I found out by experimenting and is the reason why I am
asking. From what I see on i386,
struct entrystruct * entry __attribute__ ((packed));
is interpreted as "packed pointer to struct"
not as "pointer to packed struct",
i.e. this construct is not meaningful.
> Though I'm not sure what putting the packed
> attribute on e1 will buy you.
You've got the point - I am collecting ammunition to fight a stubborn
original author :-)
Ralf
Re: struct __attribute((packed));
On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote:
> What?! That whole section in the docs talks about attributes on types.
> If it doesn't work as described, then the docs need some serious rework.
>From what I see, the example for packed types doesn't even compile:
(Direct cut'n'paste from
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-
Attributes):
# cat tmp.c
struct my_unpacked_struct
{
char c;
int i;
};
struct my_packed_struct __attribute__ ((__packed__))
{
char c;
int i;
struct my_unpacked_struct s;
};
# gcc -Wall -o tmp.o -c tmp.c
tmp.c:8: error: syntax error before '{' token
tmp.c:12: error: syntax error before '}' token
# gcc --version
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
Ralf
Re: Targets using implicit extern "C"
On Sun, 2005-05-08 at 23:34 +, Joseph S. Myers wrote:
> The following targets (based on wildcarded entries from config.gcc) do
> *not* appear to define NO_IMPLICIT_EXTERN_C, i.e. GCC is configured to
> suppose their headers are not C++-aware and to add an implicit extern
> "C" around them. Are there any in this list which should not be,
> i.e. which should be presumed to have C++-aware headers? Conversely,
> are there any in this list whose maintainers can confirm that the
> headers are not C++-aware and so the current configuration is correct?
> Many are generic embedded targets with no fixed set of system headers,
> but in such cases is the implicit extern "C" really the right default?
> Note: if you belive your target should define NO_IMPLICIT_EXTERN_C but
> doesn't, then I suggest preparing and testing the appropriate patch to
> define it; I'd rather that no such changes are mixed up with inverting the
> sense of the target macro used.
FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
system headers are c++ aware"), therefore it is hardly possible or
useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
(*-elf, *-coff etc.).
Ralf
Re: Targets using implicit extern "C"
On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> > system headers are c++ aware"), therefore it is hardly possible or
> > useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> > (*-elf, *-coff etc.).
>
> I'm going to ask you to think again about that assessment, because
> 'implicit extern C' mode is actually trouble if the headers *are* C++
> aware
The point is: You don't know, because you don't know which kind of
headers/libc is using a user is going to build gcc against.
I.e. any assumption is equally wrong unless you exactly know which kind
of headers/libc you are building against (e.g. recent versions of newlib
are supposed to have c++ aware headers, so any targets implying newlib
could (rather) safely use NO_IMPLICIT_EXTERN_C).
> -- look back through the bug database for cases. And my
> suspicion is that nowadays, the headers that generic targets do have
> are more likely to be C++ aware than not.
Agreed.
Ralf
Re: Targets using implicit extern "C"
On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
> >> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >>
> >> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> >> > system headers are c++ aware"), therefore it is hardly possible or
> >> > useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> >> > (*-elf, *-coff etc.).
> >>
> >> I'm going to ask you to think again about that assessment, because
> >> 'implicit extern C' mode is actually trouble if the headers *are* C++
> >> aware
> >
> > The point is: You don't know, because you don't know which kind of
> > headers/libc is using a user is going to build gcc against.
>
> This is true. The question in my mind is which failure mode is worse,
> and honestly I don't know.
Neither do I.
My template answer to such kind of problems is
* Try to detect it with autoconf magic (Probably difficult to implement
for "multi-staged builds", may-be impossible for "one-tree builds")
* In cases detection isn't possible, fall back to "reasonable
defaults" (e.g. --with-newlib, *-rtems*, *-linux* could imply
-DNO_IMPLICIT_EXTERN_C)
* Additionally provide a configure option to enable users to override
autoconf-provided results.
Ralf
Re: Moving the pkgconfig directory from lib/ to libdata/?
On Wed, 2005-05-11 at 22:42 +0200, Gerald Pfeifer wrote: > On Wed, 11 May 2005, Roman Kennke wrote: > >>> Is the pkgconfig directory at the correct location when put under lib/, > >>> or shouldn't this be libdata/ instead? > >> What system has $(prefix)/libdata? None I'm familiar with. > > The BSDs for example use libdata dirs. I suppose the patch is from a BSD > > port? > > Yes, indeed. It came from a FreeBSD user. > > So I guess I should rephrase $SUBJECT as: How can we properly set the > pkgconfig directory to $(prefix)/libdata/ for FreeBSD and potentially > others? Using $(prefix)/libdata without any doubt would be wrong. > Any chance for someone with auto* skills to hack this up? There is no real need to do so. make pkgdatadir=/libdata install already should do the job. Ralf
Re: GCC 4.1: Buildable on GHz machines only?
On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote: > Until package maintainers take cross-compilation *seriously*, I have > no choice but to do native compilation of a large hunk of the packages > on eval boards that can literally takes *DAYS* to build. The most amazing fact to me is: Not even GCC seems to take cross- compilation seriously :( Ralf
Re: GCC 4.1: Buildable on GHz machines only?
On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
> On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
> > On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> > > Until package maintainers take cross-compilation *seriously*, I have
> > > no choice but to do native compilation of a large hunk of the packages
> > > on eval boards that can literally takes *DAYS* to build.
> >
> > The most amazing fact to me is: Not even GCC seems to take cross-
> > compilation seriously :(
>
> BS. Even the large disto builders do cross compilations a lot.
So I suppose you have these general crossbuilding PRs fixed in your
sources:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247
Another one I haven't filed yet, is GCC-4.x not correctly propagating
CFLAGS/CFLAGS_FOR_{BUILD|HOST|TARGET} to newlib in one-tree builds (I am
still investigating).
All these to me are strong indications that GCC-4.x has been poorly
tested in cross compilation.
Ralf
Re: GCC 4.1: Buildable on GHz machines only?
On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote: > On Tuesday 17 May 2005 03:16, Joe Buck wrote: > > On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote: > > > On Tuesday 17 May 2005 02:59, Steven Bosscher wrote: > > > > Oh, and how helpful of you to post that patch to gcc-patches@ too... > > > > NOT! > > > > > > Ah, I see you did post it to gcc-patches@, but not to fortran@, which > > > is a requirement for gfortran patches -- and the reason why nobody > > > has noticed the patch. > > > > > > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02287.html > > > > > > The patch is OK too. > > > > Steven, please try to be politer to someone who is trying to help. > > How is it helpful to not follow the rules when posting patches Quite simple: * I wasn't aware about this fortran specific patch posting policy. I never have sent any gcc patch to any other list but gcc-patches for approval before, so I also had not done so this time. * How could I know that the responsible maintainers aren't listening to bugzilla and gcc-patches, but are listening to a fortran specific list, I even didn't know about until your posting? > and > make exaggerated claims that something does not work? I don't see where I exaggerated. The fact that nobody before has hit these obvious issues, to me are "just leaks" in GCC's QA/testing procedures/procedures, which ought to be closed. If I weren't interested in seeing these closed, I would not complain/file PRs on the and would not contribute/try to contribute patches. > > This kind of tone will only discourage contributors. > > My tone was no different than Ralf's toward me. Well, I admit I had been sarcastic/fatalistic in replying to Steven, primarily, because I am pretty much frustrated about GCC's mainstream developer's position/attitude on embedded targets. Steven's answers perfectly queue-in into a long history of incidents which had lead me to my understanding of "GCC mainstream developers' attitude" on "embedded targets", which I already had described in former postings. Ralf
Re: GCC 4.1: Buildable on GHz machines only?
On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote: > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote: > > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote: > > > > > No, I just don't build gfortran as a cross. There are many reasons > > > why this is a bad idea anyway. > > > > Such as? > > For one thing, libgfortran requires c99 support, which is not in > newlib iiuc. More details please. Are you referring to stdint.h/inttypes.h etc.? newlib/RTEMS has them, as well as newlib+cygwin Ralf
Re: GCC 4.1: Buildable on GHz machines only?
On Tue, 2005-05-17 at 12:52 +0200, Steven Bosscher wrote: > On May 17, 2005 12:21 PM, Ralf Corsepius <[EMAIL PROTECTED]> wrote: > > > On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote: > > > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote: > > > > > > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote: > > > > > > > > > No, I just don't build gfortran as a cross. There are many reasons > > > > > why this is a bad idea anyway. > > > > > > > > Such as? > > > > > > For one thing, libgfortran requires c99 support, which is not in > > > newlib iiuc. > > > > More details please. > > > > Are you referring to stdint.h/inttypes.h etc.? > > newlib/RTEMS has them, as well as newlib+cygwin > > Some other newlib (and non-newlib) targets don't, see PR14325 and > PR16135. Well, extending the approach I chose to implement in newlib/RTEMS to other target probably isn't too difficult, as well as it probably might be possible to merge this approach into GCC. > There was also some issue with c99 math functions that I > have not followed closely. Some fixes for this went in for HP-UX > and Solaris. I don't know if newlib always provides all the math > functions libgfortran asks for. Neither do I know for sure, but so far, libgfortran's configure script hasn't reported any problems. > Note that I did not mean to imply that gfortran should not be > buildable as a cross, just that I know that there used to be some > problems with this. There still are further problems on some targets (PR21203), but c99 and math functions don't currenlty seem to be a problem with RTEMS/newlib. Ralf
Re: GCC 4.1: Buildable on GHz machines only?
On Tue, 2005-05-17 at 12:11 -0500, Joel Sherrill wrote: > Joe Buck wrote: > > > > I used to be an embedded programmer myself, and while I cared very much > > about the size and speed of the embedded code I wound up with, I didn't > > care at all about being able to run the compiler itself on a machine that > > wasn't reasonably up to date, much less trying to bootstrap the compiler > > on an embedded target. Is that really what we should be aiming for? Well, an embedded programmer won't care much about this issue, but as RTEMS maintainer, I am building and packaging the toolchains - so GCC building times are a concern to me. > > As > > opposed to just making -Os work really well? ACK, this is an issue as well. ATM, I am experiencing objects being generated by GCC to increase in size and forcing us to gradually abandon targets with tight memory requirements. At least one cause of this seems to be GCC abandoning COFF in favor of ELF, which seems to imply larger memory requirements. > If I could get better embedded > > code by having the compiler use a lot of memory, but I could easily afford > > a machine with that amount of memory, I would have had no complaint. ACK. > There are at least three classes of development I have noticed on this > thread: > >(1) self-hosting gcc on slow but traditional hosts (e.g. 68040 UNIX > or old Sun's) >(2) self-hosted embedded development (e.g. sounds like Peter Barada) >(3) embedded development using regular cross-compilation > > In general all are concerned about lower end CPUs than are used for > the mainstream GCC user on GNU/Linux and other UNIces. > > (1) and (2) are similar and probably have similar requirements. They > would like building GCC and running it to be possible on what would > be considered low end hardware for main-stream development purposes. > > (3) is the model for RTEMS, other RTOSes, no-OS targets, and could > be the model used by (2). I won't include (1) because they want their > systems to be self supporting and users will compile their own code. > > We are all concerned about the time and memory required to build GCC. > But it is a critical concern for (1) and (2) since they are on small > hosts. For (3) and RTEMS, it concerns us because the RTEMS Project > provides RPMs for 11 targets and tries to include every language > we can possibly support (C, C++, Ada, FORTRAN, and Java). I know for > the targets that it compiles on, RTEMS works well with C, C++, and Ada. > I am unsure about the precise status of RTEMS+Java gcj builds for most RTEMS-targets. RTEMS support for libgcj and its infrastructure is missing and probably won't be implemented any time soon. A usable gcj+libgcj for RTEMS is not in sight. > and FORTRAN is currently up for discussion. gfortran builds fine for all CPUs, building libgfortran fails for some CPUs, which don't meet the expectations of gfortran/f95. Objc builds without problems for all targets. Ada builds for all CPUs Ada supports, but suffers from general cross- building deficits and lacks multilibs. > Our tool build times are thus very long > and when we follow up by building RTEMS and add-on libraries, it > gets longer. We struggle to keep up which is why RTEMS reports are > sporadic and tend to cluster nearer a release point. Be lucky, we can't build libgcj and gnat doesn't support multilibs. I would not expect us to handle this. > > It therefore seems that we have two *separate* problems: one is > that > > increased resource consumption makes gcc harder to use as a hosted > > compiler on older systems, and the other is that embedded target support > > isn't getting the attention it needs > [..] > > it seems sometimes they get mixed solely because too many > > free software projects don't support cross-compilation properly, but > > that is a bug in those projects. > > You are correct. Many free libraries have rough edges when cross- > building. My point is: GCC also has them, and could do better wrt. this. Ralf
CFLAGS in one-tree style cross builds w/ newlib
Hi, As it seems to me, CFLAGS handling with newlib+gcc-4.0.x one-tree style cross-builds seems broken. So far I have tried different permutations of setting CFLAGS, CFLAGS_FOR_BUILD, CFLAGS_FOR_HOST and CFLAGS_FOR_TARGET, but have not been successful so far. Therefore - question: How is one supposed to pass custom CFLAGS to the host-compiled components in GCC without breaking newlib? Ralf
svn troubles
Hi, I don't seem to be able to access svn: # svn ls svn://gcc.gnu.org/svn/gcc [several (2-3) minutes pass, during which svn is non-interruptable] svn: Can't connect to host 'gcc.gnu.org': Connection timed out Ralf
Re: svn troubles
On Fri, 2005-10-28 at 08:49 +0200, Andreas Jaeger wrote: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I don't seem to be able to access svn: > > > > # svn ls svn://gcc.gnu.org/svn/gcc > > [several (2-3) minutes pass, during which svn is non-interruptable] > > svn: Can't connect to host 'gcc.gnu.org': Connection timed out > > I didn't read that it's up again after the switch from CVS to SVN - I > suggest to wait until Danny sends the announcement, OK, sorry, I must have missed this in all the svn related mail floods. Ralf
Re: svn troubles
On Fri, 2005-10-28 at 08:49 +0200, Andreas Jaeger wrote: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I don't seem to be able to access svn: > > > > # svn ls svn://gcc.gnu.org/svn/gcc > > [several (2-3) minutes pass, during which svn is non-interruptable] > > svn: Can't connect to host 'gcc.gnu.org': Connection timed out > > I didn't read that it's up again after the switch from CVS to SVN - I > suggest to wait until Danny sends the announcement, For the record: This wasn't the only cause. My firewall/router blocked the svn-port (port 3690/tcp) ;) Ralf
Re: Ada on ARM
On Mon, 2005-11-21 at 17:14 +0100, Frédéric PRACA wrote: > Hi, > I'm currently trying to build an Ada cross compiler for ARM using the > arm-rtems > target. I tried with GCC 4.0.2 and subversion-version but I failed. > What should I know to do this knowing that I already built the C and C++ > cross-compilers ? 1. Replace your host compiler with the same version you want to build cross (Ada requirement). 2. The standard RTEMS toolchains are multilib'ed, Gnatlib in gcc-4.0.x doesn't support multilibs => The only chance you have is to build a non-multilib'ed custom RTEMS-GCC. 3. GNAT from GCC < 4.0.2 did not support the arm. I haven't tried gcc-4.0.2 and don't know if anybody has meanwhile added arm-support to GNAT. All in all, I think you've lost ... :( Ralf
Re: Ada on ARM
On Mon, 2005-11-21 at 13:48 -0600, Joel Sherrill wrote:
> I also have this arm-rtems specific patch. Something changed after
> 4.0.x and none of the RTEMS BSPs would link before I added this.
>
> Index: gcc/config/arm/rtems-elf.h
> ===
> --- gcc/config/arm/rtems-elf.h (revision 107316)
> +++ gcc/config/arm/rtems-elf.h (working copy)
> @@ -37,3 +37,10 @@
> #undef SUBTARGET_EXTRA_ASM_SPEC
> #define SUBTARGET_EXTRA_ASM_SPEC "\
> %{!mhard-float: %{!msoft-float:-mfpu=softfpa}}"
> +
> +/*
> + * The default includes --start-group and --end-group which conflicts
> + * with how this used to be defined.
> + */
> +#undef LINK_GCC_C_SEQUENCE_SPEC
> +#define LINK_GCC_C_SEQUENCE_SPEC "%G %L"
I fail to see what this patch is good for.
All rtems targets use the default LINK_GCC_C_SEQUENCE_SPEC and I fail to
understand why the arm should be an exception.
I'd suspect bugs in RTEMS bsp_specs hitting you.
Ralf
sizeof((..))
Hi,
gcc emits an error, when compiling this code-snippet:
--- snip ---
extern int x;
void
foo (void)
{
x = sizeof ((long));
}
--- snip ---
# gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function ‘foo’:
tmp.c:6:21: error: expected expression before ‘)’ token
# gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
# sparc-rtems4.11-gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function 'foo':
tmp.c:6:21: error: expected expression before ')' token
# sparc-rtems4.11-gcc --version
sparc-rtems4.11-gcc (GCC) 4.5.2 20101216 (RTEMS
gcc-4.5.2-3.fc14/newlib-1.19.0-1.fc14)
Any explanations? What is wrong?
FWIW: I encountered this error when checking libstdc++'s config.log,
after having noticed its configure script was producing bogus results.
The code-snippet above is a stripped down fragment of one of these
failing configure-checks.
Ralf
Re: sizeof((..))
On 01/31/2011 10:19 AM, Jonathan Wakely wrote:
On 31 January 2011 08:59, Ralf Corsepius wrote:
Hi,
gcc emits an error, when compiling this code-snippet:
--- snip ---
extern int x;
void
foo (void)
{
x = sizeof ((long));
}
--- snip ---
# gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function ‘foo’:
tmp.c:6:21: error: expected expression before ‘)’ token
# gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
# sparc-rtems4.11-gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function 'foo':
tmp.c:6:21: error: expected expression before ')' token
# sparc-rtems4.11-gcc --version
sparc-rtems4.11-gcc (GCC) 4.5.2 20101216 (RTEMS
gcc-4.5.2-3.fc14/newlib-1.19.0-1.fc14)
Any explanations? What is wrong?
The code is wrong.
It's code GCC's configure scripts apply.
AFAICT, these fragments seems to originate from autoconf and don't have
seem to cause any harm (but confusing the reader of config.logs).
ATM, I am not sure, if what autoconf does actually is useful, but this
is a different matter.
sizeof expects either an expression, or a
parenthesized type-id. (long) is not a type-id so ((long)) is not a
parenthesized type-id, therefore it must be interpreted as an
expression, but it's not a valid expression either.
Thanks for the explanation.
Ralf
Re: sizeof((..))
On 01/31/2011 01:02 PM, Andreas Schwab wrote: Ralf Corsepius writes: ATM, I am not sure, if what autoconf does actually is useful, but this is a different matter. autoconf needs to deliberately trigger errors in a lot of its tests in order to do the right thing. I know, but ... ... the autoconf macro in question is this (from .../share/autoconf/types.m4) ... m4_define([_AC_CHECK_TYPE_NEW], [AS_VAR_PUSHDEF([ac_Type], [ac_cv_type_$1])dnl AC_CACHE_CHECK([for $1], [ac_Type], [AS_VAR_SET([ac_Type], [no]) AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT([$4])], [if (sizeof ($1)) return 0;])], [AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT([$4])], [if (sizeof (($1))) return 0;])], [], [AS_VAR_SET([ac_Type], [yes])])])]) AS_VAR_IF([ac_Type], [yes], [$2], [$3])[]dnl AS_VAR_POPDEF([ac_Type])dnl ])# _AC_CHECK_TYPE_NEW ... I.e. to check for presence of a type, it 1st tries to compile if (sizeof () return 0; and then if (sizeof (()) return 0; and expects the 1st compile to succeed and the 2nd to fail. However, the rationale why autoconf is doing so, so far escapes me. Ralf
cc1: warning: unrecognized command line option "-Wno-narrowing"
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. Ralf
Re: powerpc rs6000_explicit_options change help request
On 11/08/2011 04:44 AM, 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.
I am not sure, either, but your code matches what other files being
found in GCC trunk.
I so far have been experimenting with a less intrusive patch:
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 2c0c73b..6c36e94 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -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_rs6000_float_gprs) \
rs6000_float_gprs = 1; \
-if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe)\
+if (rs6000_float_gprs != 0 && !global_options_set.x_rs6000_spe)
\
rs6000_spe = 1; \
-if (rs6000_spe && !rs6000_explicit_options.spe_abi)\
+if (rs6000_spe && !global_options_set.x_rs6000_spe_abi)
\
rs6000_spe_abi = 1; \
}
\
} while(0)
gcc-4.6.2 fails to build on fedora 17
Hi,
Crossbuilding gcc-4.6.2 for rtems targets succeeds on Fedora 15, 16,
openSUSE-11.4 and 12.1, but fails with this error on Fedora rawhide
(aka. Fedora 17):
...
# gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c -g
-O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6.2/gcc -I../../gcc-4.6.2/gcc/.
-I../../gcc-4.6.2/gcc/../include -I../../gcc-4.6.2/gcc/../libcpp/include
-I../../gcc-4.6.2/gcc/../libdecnumber
-I../../gcc-4.6.2/gcc/../libdecnumber/dpd -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:8735:18: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8854:36: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8938:31: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8959:31: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8966:31: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8973:31: error: subscripted value is neither array nor
pointer nor vector
make[2]: *** [gtype-desc.o] Error 1
Poking around inside of the build-trees, I found this difference in the
GCC-generated sources between Fedora 16 and rawhide, which I am inclined
to believe to be related to this breakdown:
diff -u
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gt-cp-mangle.h
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc
---
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gt-cp-mangle.h
2012-01-23 08:26:19.056369396 +0100
+++
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gt-cp-mangle.h
2012-01-23 08:26:38.648665206 +0100
@@ -39,7 +39,7 @@
{
&G.substitutions,
1,
-sizeof (G.substitutions),
+sizeof (G),
>_ggc_mx_VEC_tree_gc,
>_pch_nx_VEC_tree_gc
},
diff -u
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gtype-desc.c
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4
---
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gtype-desc.c
2012-01-23 08:26:19.058369427 +0100
+++
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gtype-desc.c
2012-01-23 08:26:38.652665266 +0100
@@ -8375,7 +8375,7 @@
{
&ipa_escaped_pt.vars,
1,
-sizeof (ipa_escaped_pt.vars),
+sizeof (ipa_escaped_pt),
>_ggc_mx_bitmap_head_def,
>_pch_nx_bitmap_head_def
},
...
Any ideas about the cause?
I am inclined to believe some tool (The native gcc, make, bash, sed,
awk?) being involved into generating these files could be misbehaving in
rawhide.
Ralf
Re: gcc-4.6.2 fails to build on fedora 17
On 01/23/2012 06:02 PM, Markus Trippelsdorf wrote:
On 2012.01.23 at 16:45 +0100, Ralf Corsepius wrote:
Hi,
Crossbuilding gcc-4.6.2 for rtems targets succeeds on Fedora 15, 16,
openSUSE-11.4 and 12.1, but fails with this error on Fedora rawhide
(aka. Fedora 17):
...
# gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c -g
-O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6.2/gcc -I../../gcc-4.6.2/gcc/.
-I../../gcc-4.6.2/gcc/../include -I../../gcc-4.6.2/gcc/../libcpp/include
-I../../gcc-4.6.2/gcc/../libdecnumber
-I../../gcc-4.6.2/gcc/../libdecnumber/dpd -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:8735:18: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8854:36: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8938:31: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8959:31: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8966:31: error: subscripted value is neither array nor
pointer nor vector
gtype-desc.c:8973:31: error: subscripted value is neither array nor
pointer nor vector
make[2]: *** [gtype-desc.o] Error 1
Poking around inside of the build-trees, I found this difference in the
GCC-generated sources between Fedora 16 and rawhide, which I am inclined
to believe to be related to this breakdown:
diff -u
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gt-cp-mangle.h
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc
---
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gt-cp-mangle.h
2012-01-23 08:26:19.056369396 +0100
+++
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gt-cp-mangle.h
2012-01-23 08:26:38.648665206 +0100
@@ -39,7 +39,7 @@
{
&G.substitutions,
1,
-sizeof (G.substitutions),
+sizeof (G),
>_ggc_mx_VEC_tree_gc,
>_pch_nx_VEC_tree_gc
},
diff -u
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gtype-desc.c
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4
---
/var/lib/mock/fedora-16-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gtype-desc.c
2012-01-23 08:26:19.058369427 +0100
+++
/var/lib/mock/fedora-17-x86_64-rtems/root/builddir/build/BUILD/rtems-4.11-sparc-rtems4.11-gcc-4.6.2/build/gcc/gtype-desc.c
2012-01-23 08:26:38.652665266 +0100
@@ -8375,7 +8375,7 @@
{
&ipa_escaped_pt.vars,
1,
-sizeof (ipa_escaped_pt.vars),
+sizeof (ipa_escaped_pt),
>_ggc_mx_bitmap_head_def,
>_pch_nx_bitmap_head_def
},
...
Any ideas about the cause?
I've opened a bug for this issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969
It only happens if you try to build gcc-4.6 with gcc-4.7 on my machine.
This applies in my case. rawhide's native gcc is a gcc-4.7 variant.
Ralf
gcc -r
Hi, 2 questions: 1) Is "gcc -r" officially supported by gcc? It apparently works, but I can't find it documented anywhere in GCC's documentation. 2) Is "gcc -r" any different from using "gcc -Wl,-r"? Ralf
Re: gcc -r
On Tue, 2008-12-09 at 07:19 -0800, Ian Lance Taylor wrote: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > 1) Is "gcc -r" officially supported by gcc? > > > > It apparently works, but I can't find it documented anywhere in GCC's > > documentation. > > When invoking the linker, a -r option on the command line will be > passed to the linker. The same is true of -A, -d, -eSYM, -m, -N, -n, > -s, -t, -uSYM, -x, -z, -Z. This is not well documented. OK, thanks for the explanation. > > 2) Is "gcc -r" any different from using "gcc -Wl,-r"? > > No. So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ? Ralf
Re: gcc -r
On Tue, 2008-12-09 at 08:10 -0800, Adam Nemet wrote: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > >> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ? > > > > Ah, when you put the question like that, I would recommend "ld -r". > > This is the one case where you get no advantage from using the gcc > > driver to invoke the linker, and it can actually mess you up by adding > > unexpected files to the command line. I know - We've recently been bitten by it ;) > If a different linker emulation needs to be selected you're still better off > using gcc. E.g., on linux64 n64 this: > > gcc -nostdlib -Wl,-r -mabi=64 ... > > is probably easier to remember than this: > > ld -melf64btsmip -r ... I guess, I need to provide some background information: In RTEMS, for historical reasons, we have been using: gcc ... -nostdlib -Wl,-r ... So, my questions actually were aiming at * whether "gcc ... -nostdlib -r" and "gcc ... -nostdlib -Wl,-r" are equivalent * if the fact that "gcc -r" appears to work, can be exploited or whether this is a "random accident" and/or intentionally undocumented feature, which may go away at any time. Ralf
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Joe Buck wrote: On Thu, Mar 26, 2009 at 05:11:04PM -0700, Joel Sherrill wrote: Tim Prince wrote: Kaveh R. Ghazi wrote: What versions of GMP/MPFR do you get on your typical development box and how old are your distros? For the RTEMS Project machines we try to stay on fairly recent Fedora versions. I still have to deal with older distros (e.g. RHEL 4), but it's already necessary to use newer gmp and gas versions, as well as a newer mpfr version, in that case. For the RTEMS's toolchain packages on such "stagnating OSes", we resort to bundling "sufficiently recent enough" mpfr/gmp-source tarballs with the GCC-sources and building them "in-GCC-source-tree" instead of using the host provided system-libs. One ends up with GCC being statically linked against these libmpfr/gmp's on such OSes. I do see that FreeBSD Ports has mpfr 2.4.1. How advanced of them. Amazing :-() Ralf
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Gerald Pfeifer wrote: On Fri, 27 Mar 2009, Ralf Corsepius wrote: I do see that FreeBSD Ports has mpfr 2.4.1. How advanced of them. Amazing :-() It's possible I am missing something here. According to http://www.mpfr.org/mpfr-current/ (reachable from http://www.mpfr.org/ by following "Latest release") this is the latest official release, but your comments seem to indicate there is a problem with that? Pardon, there seems to be a misunderstanding. I only was surprised to see FreeBSD shipping much newer versions of packages than most Linux distros (even those who claim to be "(b)leading edge"). Ralf
Re: Building Secondary Languages After Newlib is Installed
On 01/27/2011 07:15 PM, Joel Sherrill wrote: Hi, There are now 14 RTEMS targets which I try to test regularly on the head. Where possible, I try to test C, C++, Ada, and Go. The procedure is roughly + build and install C, C++ with newlib multilibed + build and install RTEMS + build and install C, Adawith newlib multilibed + build and install C, Gowith newlib multilibed This works well but there is no reason to spend time building newlib over and over. On targets with lots of multilibs, this takes a long time. To speed up the Ada and Go builds, I want to use the newlib installed in the first step and not build it again. But obviously the configure scripts have to pick up things correctly. libstdc++-v3/configure.ac tests $with_newlib to set a number of flags. What is the preferred combination of --enable-newlib and --with-newlib settings to build with newlib in the gcc source tree but not build it and use the installed copy for the Ada and Go builds? Theoretically, none at all, because building against an installed newlib should be equivalent to "standard cross-building". Ralf
Re: Building Secondary Languages After Newlib is Installed
On 01/28/2011 07:49 AM, Ian Lance Taylor wrote: Ralf Corsepius writes: On 01/27/2011 07:15 PM, Joel Sherrill wrote: What is the preferred combination of --enable-newlib and --with-newlib settings to build with newlib in the gcc source tree but not build it and use the installed copy for the Ada and Go builds? Theoretically, none at all, because building against an installed newlib should be equivalent to "standard cross-building". But Joel has newlib in his source tree, so won't it get built by default? That's what he wants to avoid. I realize my answer as too brief. What I had in mind was a 2 step bootstrap: 1) An initial built run, aiming at building newlib: - configure and build gcc+newlib one-tree style (--with-newlib --enable-language=c); - Install the generated newlib, do not install the gcc related parts. 2) A second build run only aiming at building gcc: - Remove the build tree. - Remove newlib from the source tree - reconfigure gcc without any newlib specific option and build again. step 2) then would be an ordinary cross-compile. Actually, unless the set of multilibs changes (and changes to gcc are moderate), step 1) is only necessary once and can be replaced with standalone building newlib. Then this all would collapse to a traditional incremental gcc+libc building scheme. (I say this without having tested it.) It's been a while since I tried this. It once used to work. Ralf
Re: Building Secondary Languages After Newlib is Installed
On 01/28/2011 10:15 AM, Andreas Schwab wrote: Ralf Corsepius writes: - Remove newlib from the source tree --without-newlib should probably be enough. Good point, agreed. In case of Joel and rtems the situation probably can be furtherly simplified: RTEMS has gcc-4.5.5-compiled newlib-rpms - Provided the set of multilibs hasn't changed (and gcc hasn't changed too much), it probably will suffice to install these newlib rpms and use them to build gcc against them. Ralf
Re: Building Secondary Languages After Newlib is Installed
On 01/28/2011 04:17 PM, Ian Lance Taylor wrote: Andreas Schwab writes: Ralf Corsepius writes: - Remove newlib from the source tree --without-newlib should probably be enough. But that seems strange to me as some of the configure scripts test for --with-newlib and adjust their configury accordingly. This would put them in a position where they actually are using newlib but are told that they are not. It might well be that they will do feature tests and come up with the right result, but I am frankly skeptical that this will happen with libstdc++-v3 at least, as it does do specific target tests. OK, something in need to be looked into (I haven't in recent times). However, as RTEMS is defacto tied to newlib and rtems-gccs could be made compilable without --with/without-newlib + external newlib. Ralf
Re: Building Secondary Languages After Newlib is Installed
On 01/28/2011 05:48 PM, Joel Sherrill wrote:
On 01/28/2011 09:17 AM, Ian Lance Taylor wrote:
Andreas Schwab writes:
Ralf Corsepius writes:
- Remove newlib from the source tree
--without-newlib should probably be enough.
But that seems strange to me as some of the configure scripts test for
--with-newlib and adjust their configury accordingly. This would put
them in a position where they actually are using newlib but are told
that they are not. It might well be that they will do feature tests and
come up with the right result, but I am frankly skeptical that this will
happen with libstdc++-v3 at least, as it does do specific target tests.
libstdc++-v3/configure.ac around line 230:
# First, test for "known" system libraries. We may be using newlib
even
# on a hosted environment.
if test "x${with_newlib}" = "xyes"; then
os_include_dir="os/newlib"
AC_DEFINE(HAVE_HYPOT)
Yes, I just also noticed this place.
Several details are with this if do not seem right:
a) the hardcoded AC_DEFINE(HAVE_ICONV)
RTEMS doesn't have iconv
b) when using an external newlib binary, the libstdc++'s standard math
checks should "just work", because modern RTEMS newlib is supposed to
have most of complex and c99's math.
There are other non-with/without-newlib related issues in
libstdc++/acinclude.m4 which seem suspicious wrt. RTEMS to me, but I
haven't investigated in depth, yet.
Ralf
Re: i386-rtems does not build on head
On Fri, 2006-02-03 at 09:45 -0600, Joel Sherrill wrote: > >>>The problem is with using stdint.h integer types without checking if > >>>they are actually > >>>available. I have posted a fix for this already that needs to be > >>>reviewed. Along with > >>>some other fixes for similar target OS dependent bugs. Patch is here: > >>>http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00032.html > >>>(and this is PR26050). > >>> > >>> > > After running autoconf, it fails a bit differently. Output below my > signature. I can reproduce the breakdown ... > But something doesn't seem right. *-rtems* and other newlib targets > have a stdint.h. Right, but .. AFAIS, this issue isn't related to stdint.h, but to sys/types.h > In file included from > ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:21: > ../../../../gcc/libgcc-math/i386/../include/math_private.h:58: error: > expected specifier-qualifier-list before 'uint32_t' > ../../../../gcc/libgcc-math/i386/../include/math_private.h:129: error: > expected specifier-qualifier-list before 'uint32_t' > ../../../../gcc/libgcc-math/i386/../include/math_private.h:182: error: > expected '=', ',', ';', 'asm' or '__attribute__' before '__ieee754_rem_pio2' > ../../../../gcc/libgcc-math/i386/../include/math_private.h:190: warning: > type defaults to 'int' in declaration of 'int32_t' > ../../../../gcc/libgcc-math/i386/../include/math_private.h:190: error: > expected ';', ',' or ')' before '*' token [..] > control reaches end of non-void function > make[3]: *** [libsse2_la-e_acosf.lo] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-target-libgcc-math] Error 2 > make: *** [all] Error 2 IMO, the cause is obvious: To retrieve fixed-size types, libgcc-math/include/math_private.h includes and expects it to provide u_int32_t and int32_t. This assumption holds on BSD compatible systems, where sys/types.h provides these types, but according to POSIX this assumption is invalid, c.f. http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html I don't know what has triggered this issue right now, but I know there is an inconsistence on BSD-fixed size types in newlib's sys/types.h. However I doubt this is the cause of this breakdown. Ralf
GCC-4.1.x include/ssl/*.h ??
Hi, Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local) installs these headers: /usr/local/include/ssp/unistd.h /usr/local/include/ssp/string.h /usr/local/include/ssp/ssp.h /usr/local/include/ssp/stdio.h Is this behavior correct? /usr/local/include is reserved for host files. These files (Seemingly new in GCC-4.1.x) are the only host files GCC is installing when building a cross-compiler. => I am inclined to think these are installed to the wrong directory. Ralf
Re: GCC-4.1.x include/ssl/*.h ??
On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote: > Hi - > > On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote: > > On Sun, 26 Feb 2006, Ralf Corsepius wrote: > > > Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local) > > > installs these headers: > > > [...] > > Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h), > > #25938 ($PREFIX/include/gomp.h), and #18244 (include/mf-runtime.h). > > Frank, any chance you could look into the mudflup one? > > I'm not fresh on gcc configury details. If anyone can send a pointer > to the relevant autoconf or derived value, that would be great. /me thinks this isn't a bug inside of the Makefile.am, but either - a bug in toplevel configure script, which gets exposed in all the library subpackages, mentioned above (you would have to call these subpackages' configure with an explicit --includedir=
Re: GCC-4.1.x include/ssl/*.h ??
On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote: > Ralf Corsepius wrote: > > >On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote: > > > > > >>Hi - > >> > >>On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote: > >> > >> > >>>On Sun, 26 Feb 2006, Ralf Corsepius wrote: > >>> > >>> > >>>>Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local) > >>>>installs these headers: > >>>>[...] > >>>> > >>>> > >>>Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h), > >>>#25938 ($PREFIX/include/gomp.h), and #18244 (include/mf-runtime.h). > >>>Frank, any chance you could look into the mudflup one? > >>> > >>> > >>I'm not fresh on gcc configury details. If anyone can send a pointer > >>to the relevant autoconf or derived value, that would be great. > >> > >> > > > >/me thinks this isn't a bug inside of the Makefile.am, but either > >- a bug in toplevel configure script, which gets exposed in all the > >library subpackages, mentioned above (you would have to call these > >subpackages' configure with an explicit --includedir= >then) > >- a bug inside of the subpackages' configure scripts (you would have to > >compose the correct includedir inside, them). > I don't know what it is but I do hope this is considered a critical > packaging error > and fixed before a final release. Cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473 I've just attached a patch that seems to solve this issue for me. BTW, Joel, our linux->freebsd cross compilers also are facing the mudflap headers issue - the mudflap issue also is present in 4.0.x ;) Ralf
Re: GCC-4.1.x include/ssl/*.h ??
On Mon, 2006-02-27 at 15:17 +0100, Ralf Corsepius wrote: > On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote: > > Ralf Corsepius wrote: > > > > >On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote: > > > > > > > > >>Hi - > > >> > > >>On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote: > > >> > > >> > > >>>On Sun, 26 Feb 2006, Ralf Corsepius wrote: > > >>> > > >>> > > >>>>Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local) > > >>>>installs these headers: > > >>>>[...] > > >>>> > > >>>> > > >>>Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h), > > >>>#25938 ($PREFIX/include/gomp.h), and #18244 (include/mf-runtime.h). > > >>>Frank, any chance you could look into the mudflup one? > > >>> > > >>> > > >>I'm not fresh on gcc configury details. If anyone can send a pointer > > >>to the relevant autoconf or derived value, that would be great. > > >> > > >> > > > > > >/me thinks this isn't a bug inside of the Makefile.am, but either > > >- a bug in toplevel configure script, which gets exposed in all the > > >library subpackages, mentioned above (you would have to call these > > >subpackages' configure with an explicit --includedir= > >then) > > >- a bug inside of the subpackages' configure scripts (you would have to > > >compose the correct includedir inside, them). > > > I don't know what it is but I do hope this is considered a critical > > packaging error > > and fixed before a final release. > > Cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473 > > I've just attached a patch that seems to solve this issue for me. Thinking about this once more, I think my patch is equally wrong. These headers shouldn't be installed to includedir at all, but should be installed into gcc's internal include dir ($libdir/gcc/$target_alias/$version/include) Ralf
Re: 4.1.0 install mistake in libssp
On Wed, 2006-03-08 at 16:43 -0600, Joel Sherrill wrote: > Andreas Schwab wrote: > > >Joel Sherrill <[EMAIL PROTECTED]> writes: > > > > > > > >>RPM invoked make install with the prefixes overriden: > >> > >>make > >>prefix=/home/rtems/tmp/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.1.0newlib1.14.0-1-root-rtems/opt/rtems-4.7 > >> > >> > >> > > > >Why don't you just set DESTDIR? > > > > > > > Wasn't needed for years before now. :) Umm, that's not quite correct. We could not use DESTDIR for older GCCs, because it was not supported in and/or broken in GCC [1]. Until GCC-4.1, non-DESTDIR installs continued to work, therefore we continued using non-DESTDIR installs, because we had wanted to keep compatibility of our build scripts (actually rpm specs) to older GCCs - Now, non-DESTDIR installs seem to be broken. > Doing that and tweaking the RPM spec to create the info > directory if it didn't get done by make install-info seem to have > resolved things. Similar considerations as above apply to info handling. Throughout GCC's history "make info|install-info" had sometimes been required and sometimes not. For the sake of simplicity we kept on using them, though they aren't required for quite a while (newlib-infos are still not handled by GCC's toplevel configurations). Ralf [1] Several subpackages in GCC did not support DESTDIR.
Re: changing the SPARC default
On Wed, 2006-03-15 at 20:10 -0800, Alexey Starovoytov wrote: > Hi, > > The default architecture for GCC SPARC is V7. > What do gcc sparc developers think about changing it to V8PLUS? > > Few things to consider: > - v7 is legacy > . used in old Sun's sun4c systems > . 32-bit only > . no integer mul/div insns AFAICT, v7's are still in use in embedded platforms. > 1st choice (the best): > - change the default for all sparc platforms This is likely to break toolchains targetting embedded targets. I am almost 100% sure it would break sparc-rtems). > 2nd: > - change the default for Solaris 7+ and linux > > 3rd (100% safe): > - change the default for Solaris 10+ > > Also 64-bit Linux doesn't have to mean 64-bit (v9) gcc compiler, > so at the same time it would be good to change it to v8plus as well. > > All that changes can be done by easily tweaking gcc/config.gcc > by adding with_cpu=v9 I don't have an opinion on Solaris or Linux. Ralf
Re: [buildrobot] microblaze-elf / microblaze-linux
On 11/26/2013 06:38 PM, Joel Sherrill wrote: Is there something that microblaze-rtems exposes that is not already covered by other microblaze or rtems targets that are already included? I believe it was on the microblaze where someone broke the libgcc pattern for rtems by changing the pattern from XXX*-*-* to XXX*-*-elf. Correct. microblaze-rtems* is incomplete in libgcc. I have a patch pending for gcc-4.8.x, but haven't yet tried with gcc-4.9.x. Ralf
Re: [ARM] EABI and the default to short enums
On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:
Sebastian Huber writes:
On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
Sebastian Huber writes:
the default ARM EABI configuration uses short enums by default (from
"gcc/config/arm/arm.c":
/* AAPCS based ABIs use short enums by default. */
static bool
arm_default_short_enums (void)
{
return TARGET_AAPCS_BASED&& arm_abi != ARM_ABI_AAPCS_LINUX;
}
This causes a major headache for me since some libraries assume that
sizeof(any enum)> 1, e.g. the standard XDR library. Is the only
possible way to disable short enums to set the ABI to
ARM_ABI_AAPCS_LINUX? Which side effects does this have?
This question would be better asked on the mailing list
gcc-h...@gcc.gnu.org rather than gcc@gcc.gnu.org. The gcc@ mailing list
is for issues related to the development of gcc itself. Please take any
followups to gcc-help. Thanks.
You can use -fno-short-enums. However, see the note about ABI
compatibility in the -fshort-enums doc.
The problem is that I need a proper GCC ARM configuration for the
RTEMS tool chain. To do this I have to provide the right definitions
in
gcc/config/arm/rtems-eabi.h
gcc/config/arm/t-rtems-eabi
and this is clearly not a GCC user problem. The so called ARM ELF
configuration didn't use short enums by default. It seems that Linux
faced this problem before and now we have this exception in the
arm_default_short_enums() function above. I want to preserve the ARM
ELF behavior with respect to enums also in the ARM EABI configuration.
The question is now who to achieve this. One option is to set the ABI
to ARM_ABI_AAPCS_LINUX also for the RTEMS tool chain, but I am not
sure that this is the right thing.
I would recommend that RTEMS change to the ARM EABI if possible. That
is the current standard ABI on ARM platforms.
That's what Sebastian is trying to do.
It's true that the ARM
EABI is different from the previous ABIs in some respect. I believe
that would mean using ARM_ABI_AAPCS.
However, if you want to retain GNU/Linux compatibility, then using
ARM_ABI_AAPCS_LINUX is likely to be correct.
So you would recommend RTEMS to throw away ARM_ABI_AAPCS and to use
ARM_ABI_AAPCS_LINUX, which as far as I see is a
Linux-specific/proprietaty deviation from EABI?
To me, this seems "hacking" - I am actually leaning towards considering
the issues Sebastian mentions to be portability bugs in the non-GCC
components he faces this issue with.
But I am not an ARM expert.
Neither am I.
Ralf
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On 03/02/2012 02:44 PM, Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302
and shortly its mirrors. It has been generated from SVN revision 184777.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
If all goes well, I'd like to release 4.7.0 in about three weeks.
Trying to cross-build for sparc-rtems4.11 rpms fails with this:
error: Installed (but unpackaged) file(s) found:
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-ar
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-nm
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-ranlib
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-ar
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-nm
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-ranlib
Are these -gcc-{ar,nm,ranlib} really supposed to be
installed? Why? The rationale escapes me.
--gcc-{ar,nm,ranlib} surely is not correct.
Ralf
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On 03/03/2012 02:58 PM, Richard Guenther wrote:
On Sat, Mar 3, 2012 at 11:17 AM, Ralf Corsepius
wrote:
On 03/02/2012 02:44 PM, Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302
and shortly its mirrors. It has been generated from SVN revision 184777.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
If all goes well, I'd like to release 4.7.0 in about three weeks.
Trying to cross-build for sparc-rtems4.11 rpms fails with this:
error: Installed (but unpackaged) file(s) found:
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-ar
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-nm
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-ranlib
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-ar
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-nm
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-ranlib
Are these-gcc-{ar,nm,ranlib} really supposed to be
installed? Why? The rationale escapes me.
--gcc-{ar,nm,ranlib} surely is not correct.
Wasn't that fixed? ...
Dunno, I used your tarball ;)
In any case, please file a bugreport.
Will do so, ASAP.
Yes, those are supposed to be installed, they are ar/nm/ranlib wrappers
with linker-plugin support.
Hmm, makes me wonder why RH's/Fedora's gcc-4.7.0 doesn't contain them:
# rpm -qlp g/gcc-4.7.0-0.12.fc17.i686.rpm | grep bin
...
/usr/bin/c89
/usr/bin/c99
/usr/bin/cc
/usr/bin/gcc
/usr/bin/gcov
/usr/bin/i686-redhat-linux-gcc
... and what they are useful for? Is there any documentation to learn
more about them?
Ralf
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On 03/05/2012 10:12 AM, Richard Guenther wrote:
On Sat, 3 Mar 2012, Ralf Corsepius wrote:
On 03/03/2012 02:58 PM, Richard Guenther wrote:
On Sat, Mar 3, 2012 at 11:17 AM, Ralf Corsepius
wrote:
On 03/02/2012 02:44 PM, Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302
and shortly its mirrors. It has been generated from SVN revision
184777.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
If all goes well, I'd like to release 4.7.0 in about three weeks.
Trying to cross-build for sparc-rtems4.11 rpms fails with this:
error: Installed (but unpackaged) file(s) found:
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-ar
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-nm
/opt/rtems-4.11/bin/sparc-rtems4.11-gcc-ranlib
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-ar
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-nm
/opt/rtems-4.11/bin/sparc-rtems4.11-sparc-rtems4.11-gcc-ranlib
Are these-gcc-{ar,nm,ranlib} really supposed to be
installed? Why? The rationale escapes me.
--gcc-{ar,nm,ranlib} surely is not correct.
Wasn't that fixed? ...
Dunno, I used your tarball ;)
In any case, please file a bugreport.
Will do so, ASAP.
Btw, if you can help track down what goes wrong with the
gcc/Makefile.in:install-gcc-ar rule that would be helpful.
I think the bug I remember was about Go language binaries.
Correct, go had a similar issue until recently
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48410) and C++ also had it
a while (several years?) ago.
Ralf
Re: RFH - Testing targets for the switch to C++
On 04/12/2012 02:32 PM, Diego Novillo wrote: On 4/12/12 3:11 AM, Sebastian Huber wrote: Hello Diego, what is with targets that only use cross compilers like RTEMS? I think there is no need for a bootstrap? No. I'm mostly interested in the stage 0 compiler used in those targets. I want to decide what we should recommend as a minimum g++ version and/or vendor compiler version. The *-rtems4* toolchains I supply for RTEMS currently are hosted on CentOS5+6, openSUSE 11.3+12.1, Fedora 15+16+17, mingw32 and cygwin, using these OSes' native toolchains. Other folks have reported to build these toolchains under different *BSDs and MacOSX variants. That said, in my understanding, the rtems targets entries on your table do not make much sense, because the limiting factor is the host-OS. From my list above, the oldest native compiler being in use are Cygwin's GCC-3.4.4 and CentOS5's gcc-4.1.2. Ralf
Re: Option -pthread in test suite with cross compilers
On 05/18/2012 09:24 AM, Sebastian Huber wrote: Hi, if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11 target, then I get several unexpected errors due to: gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option '-pthread' gcc/testsuite/g++/g++.log:g++: error: unrecognized command line option '-pthread' The -pthread option is not necessary in RTEMS for the pthread API. I don't think that a special case in the test suite is desirable, thus we should add a dummy -pthread option to the RTEMS target configurations. Is this possible? In which file do I have to look for this? I am not sure, but AFAICT, -pthread is Linux-specific. This would mean the testsuite should be modified. Ralf
Re: Deprecate i386 for GCC 4.8?
On 12/12/2012 08:54 PM, Robert Dewar wrote: On 12/12/2012 2:52 PM, Steven Bosscher wrote: And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously... Well the embedded folk often end up with precisely this dichotomy :-) But if no sign of 386 embedded chips, then reasonable to deprecate I've never heard about them before, nor do I know how far spread their products are, however these folks seem to be producing i386-SoCs http://www.dmp.com.tw/ esp. this one http://www.dmp.com.tw/tech/vortex86sx/ Ralf
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 03:15 PM, Robert Dewar wrote: On 12/13/2012 7:26 AM, Steven Bosscher wrote: Ralf has found one such a vendor, it seems. But to me, that doesn't automatically imply that GCC must continue to support such a target. Other criteria should also be considered. For instance, quality of implementation and maintenance burden. Yes, of course these are valid concerns. It's just important to have all the facts. In particular, it would be interesting to contact this company and see if they use gcc. Perhaps they would be willing to invest some development effort? They at least mention linux and Ubuntu. c.f. http://www.dmp.com.tw/tech Ralf
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 04:53 PM, Erik Trulsson wrote: Quoting Ralf Corsepius : On 12/12/2012 08:54 PM, Robert Dewar wrote: On 12/12/2012 2:52 PM, Steven Bosscher wrote: And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously... Well the embedded folk often end up with precisely this dichotomy :-) But if no sign of 386 embedded chips, then reasonable to deprecate I've never heard about them before, nor do I know how far spread their products are, however these folks seem to be producing i386-SoCs http://www.dmp.com.tw/ esp. this one http://www.dmp.com.tw/tech/vortex86sx/ I am not 100% sure, but from looking at the documents on that page I think it is based on the i486 rather than on the i386. Neither am I ;) My impression (although I am not quite up to date with the current situation) is that many (most?) x86 CPUs used in smaller embedded systems are i48&/i586 hybrids, i.e. they are i486-compatible and also supports some (but not all) features of the i586. No idea, on http://www.dmp.com.tw/tech/vortex86sx/faq.htm#3001 they are telling the Vortex86sx doesn't have an FPU, while the "upcoming Vortex86dx" would have one. Ralf
Re: Deprecate i386 for GCC 4.8?
On 12/14/2012 10:03 AM, Erik Trulsson wrote: Well, the Intel 80486sx did not have an FPU either, while the 80486dx did have one. From the Pentium (i586) onwards all Intel x86 CPUs have been equipped with an FPU, so not having an FPU would fit in with being compatible with i486 but not the i586. Thanks, you are right. I am always forget about the SXes ;) Ralf
Re: Please don't deprecate i386 for GCC 4.8
On 12/14/2012 09:16 PM, Robert Dewar wrote: On 12/14/2012 3:13 PM, Cynthia Rempel wrote: Hi, RTEMS still supports the i386, and there are many i386 machines still in use. Deprecating the i386 will negatively impact RTEMS ability to support the i386. As Steven Bosscher said, the "benefits" are small, and the impact would be serious for RTEMS i386 users. > Since there is a significant maintenance burden for such continued support, I guess a question to ask is whether the RTEMS folks or someone using RTEMS are willing to step in and shoulder this burden. My view (with my RTEMS hat on) on this: I don't have a strong opinion on dropping the i386, but it will not be possible for me to "shoulder this burden". The primary reason for RTEMS having kept trying to support the i386 was it being the least troublesome, smallest common denominator being available on simulators for a long time. I doubt, nowadays, anybody is using RTEMS on real i386ers - Several years ago (IIRC, ca. 10), there had been at least one, that I am aware about. Ralf
Re: Please don't deprecate i386 for GCC 4.8
On 12/14/2012 10:09 PM, Richard Biener wrote: On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote: On 12/14/2012 3:13 PM, Cynthia Rempel wrote: Hi, RTEMS still supports the i386, and there are many i386 machines still in use. Deprecating the i386 will negatively impact RTEMS ability to support the i386. As Steven Bosscher said, the "benefits" are small, and the impact would be serious for RTEMS i386 users. Since there is a significant maintenance burden for such continued support, I guess a question to ask is whether the RTEMS folks or someone using RTEMS are willing to step in and shoulder this burden. Btw, while I see very sporadical testresults for arm-rtems and older results for v850 and sparc and powerpc-rtems testresult posting on gcc-testresults Correct. These results are side-effects of works from people who currently are working with these architectures, facing problems or porting RTEMS to these targets. This doesn't mean the other targets aren't used nor non functional, because RTEMS targets usually only are variants from the corresponding newlib-elf targets. no such results exist for i386-rtems in 2012 which means it's current status is in the dark. More or less correct. Older ix86-rtems-gcc's are known to work, newer ix86-rtems-gccs are known to have not yet fully understood problems (Related to soft-float math, i386 and not using a linux-libc). If you want a port to be live show that it is live by posting regular testresults to gcc-testresults. Not all of this world is Linux nor backed by large teams at companies :) We simply do not have the resources do to this. Ralf
Re: Please don't deprecate i386 for GCC 4.8
On 12/15/2012 07:02 PM, Joel Sherrill wrote: I did test i386-rtems in the past few months but it had a build breakage and I filed a PR. That issue was resolved but at that point about 1/4 of the rtems targets failed to compile. You likely are referring to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 Yes, this bug is fixed, but a follow-up discussion[1] of this as resulted into what I had called "the known and yet unresolved soft-float/i386" issues earlier in this thread. Ralf [1] Start around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175#c9 Todate, I know there are at least 2 (possibly 3) bugs interacting, one (possibly 2) in GCC and one in newlib, which render the i386/softfloat multilib variant of i386-rtems GCC non-functional.
Re: CPATH, LIBRARY_PATH, and cross-compilers
On 02/13/2013 03:49 PM, Ludovic Courtès wrote: Richard Biener skribis: On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener wrote: On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote: Joel Sherrill skribis: But it still doesn't address the situation where you have multiple cross compilers in your PATH all for different targets. Yeah, I thought about it, but couldn’t come up with a practical use case where you’d need to use different cross-compilers in a single build. When you create fat binaries. That is, a more pragmatic approach would be to not honor these environments in a cross compiler at all. Agreed. Possibly, though that’d be an incompatible change. At any rate, there’s a need for similar env. vars for cross-compilers. WDYT? I am having difficulties to imagine such a need. Ralf
Re: GCC 4.3.0 Status Report (2008-02-14)
On Thu, 2008-02-14 at 22:17 +, Joseph S. Myers wrote: > On Thu, 14 Feb 2008, Joel Sherrill wrote: > > The m68k/coldfire is suffering from this regression the > > RTEMS community really would like to see resolved. > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088 > > Please try this patch; I've had it around for a while for what looks like > a similar problem on m68k-uclinux but haven't got round to doing the > necessary regression testing (and didn't know the bug in question was a > regression, or have a reduced testcase). (Is it a regression? That bug > isn't marked as such, and only regression fixes are going on trunk at > present.) Well, what to consider to be a regression is a matter of POV. :) This PR probably doesn't qualify as a "regression" wrt. GCC's "regression definition", but to RTEMS is it one: m68k-gcc-4.2.3 worked for us, m68k-gcc-4.3 doesn't. > 2007-09-26 Joseph Myers <[EMAIL PROTECTED]> > > * config/m68k/m68k.h (DWARF_CIE_DATA_ALIGNMENT): Define. > > Index: gcc/config/m68k/m68k.h > === > --- gcc/config/m68k/m68k.h > +++ gcc/config/m68k/m68k.h > @@ -317,6 +317,8 @@ > #define STRICT_ALIGNMENT (TARGET_STRICT_ALIGNMENT) > #define M68K_HONOR_TARGET_STRICT_ALIGNMENT 1 > > +#define DWARF_CIE_DATA_ALIGNMENT -2 > + > #define INT_TYPE_SIZE (TARGET_SHORT ? 16 : 32) > > /* Define these to avoid dependence on meaning of `int'. */ > Thanks for the patch, I don't know if it does the "right thing(tm)", but it at least lets building rtems succeed, i.e. it seems to solve http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088) Ralf
Re: s-oscons technique does not work for RTEMS
On Fri, 2008-08-08 at 11:14 -0500, Joel Sherrill wrote: > Samuel Tardieu wrote: > >> "Thomas" == Thomas Quinot <[EMAIL PROTECTED]> writes: > >> > > > > Thomas> As an alternative to Arno's suggestion, maybe you could use > > Thomas> the --with-sysroot configure parameter to make the required > > Thomas> headers available to the build process. I know others have > > Thomas> used this method on some cross targets. > > > > Do you mean --with-build-sysroot? > > > I tried that and got a variation on the theme to work. > I used CFLAGS_FOR_TARGETS to pass in where the > OS include files where. I posted a patch to gcc-patches > and ACATS results to gcc-testresults. > > Thanks for the hint. Hopefully the patch is OK. It isn't big. > > FWIW cd2a24e now has a gnat bug box on sparc and powerpc. > I filed it as PR 35298. > > > For those who care, --sysroot does not work RTEMS because: > > (1) Apparently the RTEMS standard binutils RPMs do > not support sysroots. Not quite. We don't use sysroot, because we don't need it. > /home/joel/work-gnat/svn//install/powerpc-rtems4.9/bin/ld: this linker > was not configured to use sysroots > collect2: ld returned 1 exit status Correct. We don't have a sysroot, because all of our headers are inside of GCC's standard include directories. > (2) RTEMS doesn't install into a /usr/include structure. It does. What you seem to be missing is our toolchains being cross-compilers. This means our headers land in $exec_prefix/$target/include (e.g. /opt/rtems-4.9/sparc-rtems4.9/include) instead of $exec_prefix/include ... AFTER building (!) [newlib based, one-tree style building: Headers have not yet been installed while building. Building picks them up from temporary directories inside of the build tree] > According to > the gcc documentation--sysroot DIR looks in DIR/usr/[include|lib]. Not true: # touch tmp.c # /opt/rtems-4.9/bin/sparc-rtems4.9-gcc -v -c tmp.c ... ignoring nonexistent directory "/opt/rtems-4.9/lib64/gcc/sparc-rtems4.9/4.3.1/../../../../sparc-rtems4.9/sys-include" ... => /opt/rtems-4.9/sparc-rtems4.9/sys-include => the default is $exec_prefix/$target/sys-include Ralf
Re: bugzilla broken?
On Thu, 2007-05-03 at 08:54 -0700, David Daney wrote: > Ralf Corsepius wrote: > > > 1. I submitted a PR, and was asked to login several times inbetween. > > > > I have found that clearing the browser's cookie cache for the site will > often correct this problem. I've never had this problem before, ever since I am working with GCC, ... and that's a really long time ... ;) > > 2. Later I returned to "PR XXX", pressed "Create attachment" and ... > > first was asked to login, then created the attachment. > > When having finished to fill out the form, I pressed "submit" ... > > and wasn't asked for a password, instead had been greeted with the error > > message. > > > > No obvious indication of a broken/outdated cookie, no indication of a > > missing log-in (I even requested a new password in-between ;) ) > > > > I don't know what indication you were looking for or expecting. > Acknowledged that it would be nice if it didn't break. Sorry, I am heavily using other bugzillas too (e.g. redhat's), and never had this issue before ... Ralf
Re: paranoia on PowerPC
On Mon, 2007-07-23 at 19:00 -0700, Tim Prince wrote: > Should we know which version of Paranoia this is? It's the version having been integrated into the rtems source tree many years ago: http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/testsuites/samples/paranoia/paranoia.c > or guess which flaw > is reported? I'd be happy to check Paranoia on a platform to which I > have access, with a more interesting gcc version, but you've given > little to go on. cf. the thread starting at http://rtems.rtems.org/pipermail/rtems-users/2007-July/018611.html Ralf
