Hey, I'm running openSUSE 2.6.22.12-0.1-default with x86_64.
I have several files: pizza.asm, driver.c and asm_io.o
What I'm trying to do is to compile all these files to a single executable
file pizza, I use the following command:
nasm -g -f elf -d ELF_TYPE pizza.asm
gcc -m32 -o pizza -g driver.
Joe Buck wrote:
> I suggest killing the file; we could later establish a consultants web
> page for gcc.gnu.org but we could treat that as a separate issue.
I suggest killing the file as well.
I'm certainly honored that CodeSourcery is being used as an example of a
company that works on GCC in t
On Fri, 30 Nov 2007, Michael Eager wrote:
> There's also __mode__ (__SI__) in include/sys/types.h
Not in GCC. I don't know about the portability assumptions of newlib.
--
Joseph S. Myers
[EMAIL PROTECTED]
Michael Eager wrote:
Joseph S. Myers wrote:
On Tue, 27 Nov 2007, Michael Eager wrote:
I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.
Only among contributors not considering non-8-bit bytes. SImode is 4
times QImode, 4*BITS_PER_UNIT bi
Snapshot gcc-4.3-20071130 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071130/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
> volatile unsigned char y;
> void f ()
> {
> y |= 32;
> }
>
> I cannot see a reason not to use "orb $32,y" here instead of a three
> steps read/modify/write operation. Is this only a missed optimization?
No, it's purposeful. The idea was that this is completely equivalent to
y =
When looking at an Ada PR, I stumbled upon the equivalent of the
following C code:
unsigned char x;
volatile unsigned char y;
void f ()
{
x |= 16;
y |= 32;
}
With trunk/i686, the following code is generated (-O3 -fomit-frame-pointer):
f:
movzbl y, %eax
orb $
> FWIW. I see the same behavior for i386-unknown-netbsdelf3.1 too (when
> compiling natively, i.e. not using cross compiler).
For native platforms, I would suggest to switch to DWARF-2 EH, see for
example system-freebsd-x86.ads.
--
Eric Botcazou
> On the SPARC, this produced an executable I couldn't run
> on the simulator. It looked like the .text segment may
> have increased enough to not fit in the simulator.
Weird. The EH tables should probably not end up in .text.
> So this appears to work around the build time problem and
> will l
On Fri, 30 Nov 2007, Joel Sherrill wrote:
Krister Walfridsson wrote:
On Wed, 28 Nov 2007, Joel Sherrill wrote:
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling
On Fri, Nov 30, 2007 at 03:21:32AM +0100, Rask Ingemann Lambertsen wrote:
> On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
>
> > Even though current mainline can build libgfortran, all tests fail for
> > simulator testing, and I'm not sure whether you could get it work for
> >
Eric Botcazou wrote:
Doing this fixed the long build time issue but it opened issue.
OK, thanks for confirming.
It looks like the RTEMS configuration is missing something
that this requires. The first application I tried to link is missing:
+ __gnat_eh_personality
+ __gnat_begin_han
On Fri, Nov 30, 2007 at 10:25:34AM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
>
> >>>I have a feeling it would be more robust to simulate the link tests
> >>> inside the autoconf/libtool macros themselves as opposed to explicitly
> >>> avoiding them in each and every configu
On Thu, Nov 29, 2007 at 08:16:22PM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
>
> >> Perhaps we should turn target-libgfortran off by default for mips*-elf*.
> >
> >No. There is a point in excercising the compiler: Testing. In most cases,
> > you don't find problems with th
> Doing this fixed the long build time issue but it opened issue.
OK, thanks for confirming.
> It looks like the RTEMS configuration is missing something
> that this requires. The first application I tried to link is missing:
>
> + __gnat_eh_personality
> + __gnat_begin_handler
> + __gnat_end_ha
Eric Botcazou wrote:
Thank you for confirming it wasn't just me or my configuration. This
looks like a serious issue to me.
It's partly your configuration, this presumably doesn't happen on platforms
that use DWARF-2 exception handling, i.e. most native platforms (I just
re-tested SPARC
> I would prefer to revert DJ's change, for the same reason as the
> other changes under discussion, so that we're consistent across
> architectures.
I don't care as long as a combined tree still builds.
> Well it is now up to 13 minutes of compile time
> on that one file when it is 30 seconds at -O0 so
> this doesn't appear to help significantly.
OK, sounds like a real problem then.
--
Eric Botcazou
> Thank you for confirming it wasn't just me or my configuration. This
> looks like a serious issue to me.
It's partly your configuration, this presumably doesn't happen on platforms
that use DWARF-2 exception handling, i.e. most native platforms (I just
re-tested SPARC/Solaris), probably why n
Richard Sandiford wrote:
> 2006-04-18 DJ Delorie <[EMAIL PROTECTED]>
>
> * configure.in (m32c): Build libstdc++-v3. Pass flags to
> reference libgloss so that libssp can be built in a combined
> tree.
> * configure: Regenerate.
> Mark, DJ? Do you agree it's OK to drop
Rask Ingemann Lambertsen wrote:
>> The issue isn't just Newlib; it's the "BSP" (crt0, system-call
>> implementations, etc.) that you might have in your individual system.
>> Some BSPs add considerable functionality beyond that provided by Newlib
>> itself, and we don't want libstdc++ to detect and
On Wed, Nov 28, 2007 at 03:21:08PM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
>
> >Here's a detail I'm missing. If you configure --with-newlib (or get it
> > implicitly) and then link with something else when using the toolchain, then
> > the answers will be wrong, but I don
On Fri, Nov 30, 2007 at 10:03:19AM -0800, David Daney wrote:
> Also the world of GCC has change considerably since the SERVICE file was
> conceived.
>
> Most people looking for support have access to an Internet search engine
> that will probably yield results as good or better than could be
>
Joe Buck wrote:
On Fri, Nov 30, 2007 at 03:53:04PM +0100, Manuel López-Ibáñez wrote:
On 29/11/2007, Joe Buck <[EMAIL PROTECTED]> wrote:
Unfortunately, that's an area that the FSF wants tight control over;
they would be especially cheesed off if we linked to a consultant's page
and the consultan
On Fri, Nov 30, 2007 at 03:53:04PM +0100, Manuel López-Ibáñez wrote:
> On 29/11/2007, Joe Buck <[EMAIL PROTECTED]> wrote:
> >
> > Unfortunately, that's an area that the FSF wants tight control over;
> > they would be especially cheesed off if we linked to a consultant's page
> > and the consultant
On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
> libstdc++-v3/
> 2007-xx-xx Mark Mitchell <[EMAIL PROTECTED]>
>
> * configure.ac: Don't check AC_LIBTOOL_DLOPEN if using newlib.
> * configure: Regenerate.
>
> Index: libstdc++-v3/configure.ac
>
Eric Botcazou wrote:
Have you seen anything like the gnat1 compile
time I reported yesterday?
Try to configure with --enable-checking=release.
Well it is now up to 13 minutes of compile time
on that one file when it is 30 seconds at -O0 so
this doesn't appear to help significantly.
On Fri, Nov 30, 2007 at 08:44:59AM +, Richard Sandiford wrote:
> Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> > On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
> >> It sounds like we've agreed that, if we want
> >> to support libgfortran on targets like mips*-elf*,
Eric Botcazou wrote:
Thanks. That doesn't appear to be as bad as
what I am seeing.
Quite good actually.
Have you seen anything like the gnat1 compile
time I reported yesterday?
Try to configure with --enable-checking=release.
No. I will add that to the list of things to d
Krister Walfridsson wrote:
On Wed, 28 Nov 2007, Joel Sherrill wrote:
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling on Linux x86 targeting the
PowerPC or SPARC
On 29/11/2007, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> Unfortunately, that's an area that the FSF wants tight control over;
> they would be especially cheesed off if we linked to a consultant's page
> and the consultant also advertised his/her ability to support proprietary
> compiler development.
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:
>> Even though current mainline can build libgfortran, all tests fail for
>> simulator testing, and I'm not sure whether you could get it work for
>> bare-metal boards or not.
32 matches
Mail list logo
