"g...@cyberfiber.org" writes:
> can someone please comment?
1) This is definitely the wrong mailing list. Try sysad...@gnu.org.
2) Nobody can help you without much more information, like exactly
what you tried to do and exactly what happened.
3) You probably want gdb-patc...@sourceware.org.
Snapshot gcc-4.4-20091229 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091229/
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/branches
FX wrote:
Hi all,
I have picked up what seems to be a simple patch from PR36399, but I don't know
enough assembler to tell whether it's fixing it completely or not.
The following function:
#include
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
is com
Hi,
I would like to provide a kind of iPhone-like api on non apple hardware
using Objective-C
and I wanted to know if there will be one day support of Objective-C
2.0(at least property syntax) ?
Thanks
can someone please comment?
greetz,
michael
test
Hi all,
I have picked up what seems to be a simple patch from PR36399, but I don't know
enough assembler to tell whether it's fixing it completely or not.
The following function:
#include
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
is compiled by App
> Hope this helps...
Looks like something is getting really messed up in the argument parsing :-(
The error for the hexadecimal number pursing is from the code that
should handle things like
fil...@offset
This is probably from some @file not being expanded.
What I would recommend is first debu
-enable-languages=c --disable-nls --disable-bootstrap
--disable-libmudflap --disable-checking
Thread model: posix
gcc version 4.5.0 20091229 (experimental) [trunk revision 155504] (GCC)
COLLECT_GCC_OPTIONS='-B.' '-O2' '-flto' '-r' '-o' 't.o'
> I have the lto1 command line, yes. But that gives a different failure.
> When run from gcc, lto1 crashes with an ICE, and when I run lto1
> standalone, it crashes with an error reading a hex number.
Do you have a backtrace of that?
You can also copy the gcc line and pass -wrapper to it.
>
>
>>
On Tue, Dec 29, 2009 at 5:41 PM, Rafael Espindola wrote:
> 2009/12/29 Steven Bosscher :
>> Hi,
>>
>> I am trying to see what is going on in lto1 for PR lto/42534. I can
>> reproduce the reported ICE but I can't reproduce it inside gdb to see
>> what is happening. Debugging lto1 is not trivial - ju
2009/12/29 Steven Bosscher :
> Hi,
>
> I am trying to see what is going on in lto1 for PR lto/42534. I can
> reproduce the reported ICE but I can't reproduce it inside gdb to see
> what is happening. Debugging lto1 is not trivial - just getting the
> arguments and input files right is hard.
>
> App
Hi,
I am trying to see what is going on in lto1 for PR lto/42534. I can
reproduce the reported ICE but I can't reproduce it inside gdb to see
what is happening. Debugging lto1 is not trivial - just getting the
arguments and input files right is hard.
Apparently this is a known issue
(http://gcc.g
Apologies if you receive multiple copies of this call.
CALL FOR PARTICIPATION
2nd Workshop on
GCC Research Opportunities
14 matches
Mail list logo
