Hello,
The following code works in lcc in windows but it does not work in gcc in unix.
I think it is memory problem. In lcc there is an option to use more temporary
memory than the default. Is there something similar in gcc?
#include
#include
#include
#include
int main()
{
int i, j;
int buf
On Friday 14 November 2008 10:09:22 Anna Sidera wrote:
> Hello,
>
> The following code works in lcc in windows but it does not work in gcc in
> unix. I think it is memory problem. In lcc there is an option to use more
> temporary memory than the default. Is there something similar in gcc?
>
> #incl
Hi All
Looking over the bugzilla data base and archives of this (and other)
lists I was wondering about the level of support there is for GCC on
Cygwin. (I realise that it is weird half-way house to many people and
so does get a fair amount of "abuse" from both the Windoze &
Linux/Un*x purist camp
Interesting. At least. There should be a warning from gcc.
Eric
2008/11/14 Tim München <[EMAIL PROTECTED]>:
> On Friday 14 November 2008 10:09:22 Anna Sidera wrote:
>> Hello,
>>
>> The following code works in lcc in windows but it does not work in gcc in
>> unix. I think it is memory problem. In
Andy Scott wrote:
> Looking over the bugzilla data base and archives of this (and other)
> lists I was wondering about the level of support there is for GCC on
> Cygwin. (I realise that it is weird half-way house to many people and
> so does get a fair amount of "abuse" from both the Windoze &
> L
> > the code you provided tries to allocate a huge chunk of memory on the
> > stack.
> Interesting. At least. There should be a warning from gcc.
The limit is nothing to do with GCC. It is an OS setting (ulimit -s).
Paul
> The real heart of the matter though is that most of the people that
> contribute to gcc aren't themselves users of these targets, and so it's
> only natural that they don't know about or care about the status of any
> target-specific issues. What has worried me lately however is how much
> ELF-s
On 14/11/2008, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Andy Scott wrote:
>
> > Looking over the bugzilla data base and archives of this (and other)
> > lists I was wondering about the level of support there is for GCC on
> > Cygwin. (I realise that it is weird half-way house to many people an
Brian Dessent wrote:
> Cygwin has been a secondary target for a number of years. MinGW has
> been a secondary target since 4.3. This generally means that they
> should be in fairly good shape, more or less. To quote the docs:
>
>> Our release criteria for the secondary platforms is:
>>
>>
2008/11/13 Jack Howarth <[EMAIL PROTECTED]>:
> The darwin-specific gcc.dg/cpp/subframework1.c -fno-show-column test case
> is failing under gcc trunk for the excessive errors test because we now
> get warnings...
>
> warning: #import is a deprecated GCC extension
>
> Is there a particular way to m
Anna Sidera <[EMAIL PROTECTED]> writes:
> The following code works in lcc in windows but it does not work in
> gcc in unix. I think it is memory problem. In lcc there is an option
> to use more temporary memory than the default. Is there something
> similar in gcc?
In gcc, no. But if you are usi
Paul Brook wrote:
> If you really want to solve this then you could always stop using PE/COFF.
> The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates
> how this can be done. Basically the toolchain generates ELF objects,
> executables and DSOs, then you feed them through a
> > Now I'm getting a ton of errors (like, around 5000) that look like this:
>
> Just remove that assert for testing.
Looks good without the assert, 21 new passes and only 1 new failure:
PASS-FAIL: gcc.c-torture/execute/loop-ivopts-1.c execution, -O3
-fomit-frame-pointer -funroll-loops
Brian Dessent wrote:
> Paul Brook wrote:
>
>> If you really want to solve this then you could always stop using PE/COFF.
>> The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates
>> how this can be done. Basically the toolchain generates ELF objects,
>> executables and DSOs,
Tim Prince wrote:
> bootstrap failures are due to a broken #ifdef specific to cygwin in the
> headers provided with cygwin,
If you mean the strsignal change in libiberty, that's been fixed in CVS
for a long time.
> the requirement for a specific version of
> autoconf (not available in setup),
Y
2008/11/12 Bernd Roesch:
>
> But in libstdc++v3/src/functexcept.cc
>
> void
> __throw_logic_error(const char*)
> { std::abort(); }
>
> this call abort and there is no string print out, because abort get no
> Parameter as far i see.
>
> How can this work ?
It works by calling abort(), as intended
Andrew Haley wrote:
> So do that, then. Where's the problem?
I suppose it's not a problem if the alternative is no plugin support at
all. It just seems a little ugly for the plugin author to have to
distribute 'n' trivially different but substantially identical copies of
their plugin binary for
On Fri, 14 Nov 2008, Brian Dessent wrote:
> Andrew Haley wrote:
>
> > So do that, then. Where's the problem?
>
> I suppose it's not a problem if the alternative is no plugin support at
> all. It just seems a little ugly for the plugin author to have to
> distribute 'n' trivially different but
Hello all,
I tracing bug in GCC for Coldfire target, but I end in dead water and
I need some help from real experts :).
Both gcc 4.4 and 4.3 have same problem
GCC miscompile this small test case.
//-
//m68k-elf-gcc -save-temps -da -f
On Thu, Nov 13, 2008 at 11:46:04PM +, Paul Brook wrote:
> On Thursday 13 November 2008, Michael Meissner wrote:
> > On Thu, Nov 13, 2008 at 09:14:06PM +0100, Paul Chavent wrote:
> > > Hi.
> > >
> > > I wonder why there aren't any endianess attributes ?
> > >
> > > For example we could write thi
"Joseph S. Myers" wrote:
> As I understand it, there is an alternative - put all the shared code in a
> DLL on Windows if configuring with plugins enabled, and link both the
> plugins and cc1, cc1plus etc. with that DLL. If people wish to enable
The problem with that approach is that people have
Snapshot gcc-4.4-20081114 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081114/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Nov 14, 2008 at 10:23 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> > Now I'm getting a ton of errors (like, around 5000) that look like this:
>>
>> Just remove that assert for testing.
>
> Looks good without the assert, 21 new passes and only 1 new failure:
>
> PASS-FAIL: gcc.c-torture/ex
23 matches
Mail list logo
